Product SiteDocumentation Site

فصل 9. خدمات يونكس

9.1. إقلاع النظام
9.1.1. The systemd init system
9.1.2. The System V init system
9.2. تسجيل الدخول عن بعد
9.2.1. الدخول البعيد الآمن: SSH
9.2.2. استخدام سطوح المكتب الرسومية البعيدة
9.3. إدارة الصلاحيات
9.4. واجهات الإدارة
9.4.1. الإدارة على واجهة وب: webmin
9.4.2. ضبط الحزم: debconf
9.5. أحداث syslog
9.5.1. المبدأ والآلية
9.5.2. ملف الإعداد
9.6. المخدم الفائق inetd
9.7. جدولة المهام باستخدام cron وatd
9.7.1. صيغة ملف crontab
9.7.2. استخدام الأمر at
9.8. جدولة المهام غير المتزامنة: anacron
9.9. الحصص التخزينية
9.10. النسخ الاحتياطي
9.10.1. النسخ الاحتياطي باستخدام rsync
9.10.2. استعادة الأجهزة دون نسخ احتياطي
9.11. التوصيل الساخن: hotplug
9.11.1. مقدمة
9.11.2. مشكلة التسمية
9.11.3. طريقة عمل udev
9.11.4. مثال واقعي
9.12. إدارة الطاقة: Advanced Configuration and Power Interface ‏(ACPI)
يغطي هذا الفصل عدداً من الخدمات الأساسية المشتركة بين العديد من أنظمة يونكس التي يجب أن يعرفها كل مدير نظام.

9.1. إقلاع النظام

عند إقلاع الحاسب، تعرض الرسائل العديدة التي تمر على الشاشة العديد من الإعدادات وعمليات التهيئة الجارية. قد ترغب أحياناً بتعديل هذه المرحلة قليلاً، مما يعني أنك تحتاج فهمها جيداً. هذا هو الهدف من هذا القسم.
First, the BIOS takes control of the computer, detects the disks, loads the Master Boot Record, and executes the bootloader. The bootloader takes over, finds the kernel on the disk, loads and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — init. Frequently, this “root partition” and this init are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system cannot boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.
Boot sequence of a computer running Linux with systemd

شكل 9.1. Boot sequence of a computer running Linux with systemd

9.1.1. The systemd init system

The “real init” is currently provided by systemd and this section documents this init system.
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 flavours, but we will focus on “services” and “targets” here.
A systemd “service file” describes a process managed by systemd. It contains roughly the same information as old-style init-scripts, but expressed in a declaratory (and much more concise) way. Systemd handles the bulk of the repetitive tasks (starting and stopping the process, checking its status, logging, dropping privileges, and so on), and the service file only needs to fill in the specifics of the process. For instance, here is the service file for 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
As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed.
A systemd “target file” describes a state of the system, where a set of services are known to be operational. It can be thought of as an equivalent of the old-style runlevel. One of the targets is local-fs.target; when it is reached, the rest of the system can assume that all local filesystems are mounted and accessible. Other targets include network-online.target and sound.target. The dependencies of a target can be listed either within the target file (in the Requires= line), or using a symbolic link to a service file in the /lib/systemd/system/targetname.target.wants/ directory. For instance, /etc/systemd/system/printer.target.wants/ contains a link to /lib/systemd/system/cups.service; systemd will therefore ensure CUPS is running in order to reach printer.target.
Since unit files are declarative rather than scripts or programs, they cannot be run directly, and they are only interpreted by systemd; several utilities therefore allow the administrator to interact with systemd and control the state of the system and of each component.
The first such utility is systemctl. When run without any arguments, it lists all the unit files known to systemd (except those that have been disabled), as well as their status. systemctl status gives a better view of the services, as well as the related processes. If given the name of a service (as in systemctl status ntp.service), it returns even more details, as well as the last few log lines related to the service (more on that later).
Starting a service by hand is a simple matter of running systemctl start servicename.service. As one can guess, stopping the service is done with systemctl stop servicename.service; other subcommands include reload and restart.
To control whether a service is active (i.e. whether it will get started automatically on boot), use systemctl enable servicename.service (or disable). is-enabled allows checking the status of the service.
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 initialisation 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)
Another useful command-line flag is -f, which instructs journalctl to keep displaying new messages as they are emitted (much in the manner of tail -f file).
If a service doesn't seem to be working as expected, the first step to solve the problem is to check that the service is actually running with systemctl status; if it is not, and the messages given by the first command are not enough to diagnose the problem, check the logs gathered by journald about that service. For instance, assume the SSH server doesn't work:
# 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
# 
After checking the status of the service (failed), we went on to check the logs; they indicate an error in the configuration file. After editing the configuration file and fixing the error, we restart the service, then verify that it is indeed running.

9.1.2. The System V init system

The System V init system (which we'll call init for brevity) executes several processes, following instructions from the /etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.
من ضمن هذه البرامج سوف تجد –على التعاقب– برامجاً مسؤولة عن:
  • إعداد لوحة مفاتيح الطرفية؛
  • تحميل التعاريف: تحمّل النواة معظم التعاريف عند اكتشاف العتاد؛ بعدها تحمل التعاريف الإضافية آلياً إذا كانت الوحدات الموافقة لها مذكورة في /etc/modules؛
  • التحقق من سلامة نظام الملفات؛
  • ربط الأقسام المحلية؛
  • إعداد الشبكة؛
  • ربط نظم الملفات الشبكية (NFS).
After this stage, init takes over and starts the programs enabled in the default runlevel (which is usually runlevel 2). It executes /etc/init.d/rc 2, a script that starts all services which are listed in /etc/rc2.d/ and whose names start with the “S” letter. The two-figures number that follows had historically been used to define the order in which services had to be started, but nowadays the default boot system uses insserv, which schedules everything automatically based on the scripts' dependencies. Each boot script thus declares the conditions that must be met to start or stop the service (for example, if it must start before or after another service); init then launches them in the order that meets these conditions. The static numbering of scripts is therefore no longer taken into consideration (but they must always have a name beginning with “S” followed by two digits and the actual name of the script used for the dependencies). Generally, base services (such as logging with rsyslog, or port assignment with portmap) are started first, followed by standard services and the graphical interface (gdm3).
يسمح نظام الإقلاع الاعتمادي هذا بأتمتة عملية إعادة الترقيم، وهذه عملية متعبة جداً لو كانت ستتم يدوياً، كما يحد من الأخطاء البشرية، بما أن الجدولة تجري وفقاً للقيود المفروضة. هناك أيضاً ميزة أخرى، وهي أن تشغيل الخدمات يمكن أن يتم على التوازي إذا كانت مستقلة عن بعضها، وهذا يسرع عملية الإقلاع.
تفرق init بين عدة مستويات تشغيلية، بحيث يمكن التبديل من أحد هذه المستويات إلى الآخر بالأمر telinit new-level. تبدأ init فوراً تنفيذ /etc/init.d/rc مرة ثانية ولكن في المستوى التشغيلي الجديد. بعدها يبدأ هذا السكربت تشغيل الخدمات الناقصة وإيقاف الخدمات التي لم تعد مرغوبة. لإتمام هذه المهمة، يستند هذا السكربت على محتويات /etc/rcX.d (حيث X تمثل المستوى الجديد). السكربتات التي تبدأ بالحرف ”S“ (من كلمة ”Start“) هي الخدمات التي يجب تشغيلها؛ أما التي تبدأ بالحرف ”K“ (من كلمة ”Kill“) فهي الخدمات التي يجب إيقافها. لا يشغل السكربت أي خدمة كانت فعالة مسبقاً في المستوى التشغيلي السابق.
By default, System V init in Debian uses four different runlevels:
  • المستوى 0 يستخدم مؤقتاً فقط أثناء إيقاف تشغيل الحاسب. ولذلك فهو لا يحوي إلا عدة سكربتات ”K“ فقط.
  • المستوى 1، ويعرف أيضاً بوضع المستخدم الوحيد single-user mode، وهو يمثل النظام في وضع الأداء المنخفض؛ فهو يُحَمِّل الخدمات الأساسية فقط، وهو يستخدم لأغراض الصيانة بعيداً عن تفاعل المستخدمين.
  • المستوى 2 هو مستوى العمل الطبيعي، الذي يتضمن خدمات الشبكة، والواجهة الرسومية، واتصالات المستخدمين، الخ.
  • المستوى 6 يشبه المستوى 0، عدا أنه يستخدم في طور إيقاف التشغيل الذي يسبق إعادة الإقلاع.
هناك مستويات تشغيل أخرى، بالأخص المستويات من 3 إلى 5. افتراضياً تعمل هذه المستويات مثل المستوى 2 تماماً، لكن يستطيع مدير النظام تعديلها (بإضافة أو حذف سكربتات في مجلد /etc/rcX.d الموافق) لتكييفها مع حاجاته الخاصة.
Boot sequence of a computer running Linux with System V init

شكل 9.2. Boot sequence of a computer running Linux with System V init

كافة السكربتات المخزنة في مجلدات /etc/rcX.d المختلفة هي في الحقيقة روابط رمزية فقط —يُنشِئها البرنامج update-rc.d عند تثبيت الحزمة— تشير إلى السكربتات الفعلية المخزنة في /etc/init.d/. يستطيع مدير النظام ضبط الخدمات المتاحة في كل مستوى تشغيلي من خلال إعادة استدعاء update-rc.d مع البارامترات المعدلة. تشرح صفحة الدليل update-rc.d(1)‎ صيغة استخدامها بالتفصيل. نرجو أن تلاحظ أن إزالة جميع الروابط الرمزية (باستخدام البارامتر remove) ليست طريقة جيدة لتعطيل الخدمة. بل عليك إعدادها بحيث لا تعمل في المستوى التشغيلي المطلوب بكل بساطة (مع الحفاظ على الاستدعاءات الموافقة لإيقافها في حال كانت الخدمة تعمل في المستوى التشغيلي السابق). بما أن واجهة update-rc.d متشابكة نوعاً ما، فقد تفضل استخدام rcconf (من الحزمة rcconf) الذي يوفر واجهة أليفة للمستخدم.
أخيراً، تبدأ init تشغيل البرامج لمختلف الطرفيات الظاهرية (getty). بعدها تعرض سطر أوامر، الذي ينتظر إدخال اسم المستخدم، ثم تنفذ login user لبدء جلسة عمل.