Product SiteDocumentation Site

2. Зміни у Fedora для системних адміністраторів

2.1. Встановлення

2.1.1. LVM у інтелектуальному режимі (Thin Provisioning) у Anaconda

У засобі для встановлення Fedora нової версії передбачено підтримку створення томів LVM у інтелектуальному режимі (Thin Provisioning), за допомогою графічного інтерфейсу та засобу автоматичного встановлення kickstart. Зокрема, передбачено новий варіант автоматичного поділу диска на розділи, а також нові пункти для створення інтелектуальних томів у режимі нетипового поділу на розділи.

2.1.2. Каталоги документації без визначення версії

Документація до пакунків у новій версії встановлюється до каталогів, що не містять версії у назві, /usr/share/doc/назва пакунка. У попередніх версіях документація встановлювалася до каталогів, у назві яких містилися дані щодо версії пакунка.

2.2. Безпека

2.2.1. У новій версії FreeIPA передбачено підтримку перехідних відносин довіри

У FreeIPA 3.3.2 додано підтримку складних лісів Active Directory, що містять декілька доменів. Користувачі з декількох доменів AD можуть отримувати доступ до ресурсів у FreeIPA. Адміністратори FreeIPA можуть вибірково блокувати доступ для кожного з доменів AD.

2.2.2. У SSSD додано прив’язку ідентифікаторів до спільних ресурсів CIFS

У пакунку Fedora 20 System Security Services Daemon реалізовано підтримку прив’язки SID Windows до ідентифікаторів POSIX. Адміністратори, що використовують SSSD у своїх мережах, можуть встановлювати керування доступом за допомогою двох нових інструментів setcifsacl та getcifsacl.
Докладніший опис можна знайти у основному документі щодо дизайну за адресою https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient та на сторінках довідки до setcifsacl, getcifsacl, а також у довідці до інших, пов’язаних з SSSD, пакунків.

2.2.3. Засоби роботи зі спільним сертифікатом системи

Можливості спільного сертифіката системи Fedora у новому випуску було розширено за рахунок додавання програми p11-kit-trust. За допомогою відповідного пакунка можна вносити зміни до прив’язок довіри та додавати ключі і сертифікати до «чорних» списків. Адміністратори можуть вносити зміни до бази даних сертифікатів системи однією командою замість додавання файла до певного каталогу та виконання певної команди. Цим новим засобом продовжено розвиток можливостей системи спільного сертифіката системи.

2.3. Файлові системи

2.3.1. SSD-кешування для блокових пристроїв

У Fedora 20 ви зможете скористатися експериментальною підтримкою додавання твердотільних накопичувачів даних (SSD) для швидкого та прозорого кешування даних традиційних дискових накопичувачів. У файлових системах на основі блокових пристроїв з таким кешуванням поєднується швидкість роботи SSD та об’єм традиційних жорстких дисків. Кеш може бути додано до нових або вже створених стандартних розділів та сховищ LVM.

Створюйте резервні копії!

Перш ніж виконувати будь-які низькорівневі зміни у роботі дискової підсистеми, зокрема під час переходу на роботу з пристроєм додаткового кешування, завжди створюйте резервні копії даних. Доки у сховищі Fedora не з’являться пакунки, подібні до blocks, ми радимо користувачам реалізовувати bcache створенням систем «з нуля» з наступним заповненням файлових систем на них даними резервних копій попередньої конфігурації.

2.4. Віртуалізація

2.4.1. Емуляція ARM у системах x86

Внесено зміни, які надають змогу краще емулювати гостьові системи ARM у віртуальних машинах, запущених на основних системах x86, де використовуються стандартні інструменти libvirt, зокрема virsh, virt-manager та virt-install. У складі qemu передбачено емулятор ARM, який добре працює і активно використовується у проектах ARM Fedora. Втім, libvirt і virt-manager у поточних версіях мають проблеми з запуском віртуальних машин qemu-system-arm, здебільшого через використання припущення x86 у створеному командному рядку, що призводить до того, що qemu-system-arm не може запуститися. Внесено зміни, щоб виправити ці проблеми. Докладнішу інформацію можна знайти на цій сторінці: https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86

2.4.2. Керування доступом у клієнті libvirt

Клієнтська частина libvirt забезпечує встановлення правил доступу, які можна застосовувати до усіх керованих об’єктів і дій з API. Таким чином, забезпечується обмеження усіх клієнтських з’єднань за допомогою мінімального набору правил і прав доступу. Передбачено три рівні доступу, які можна призначати.
На початковому рівні для усіх з’єднань використовується режим доступу не розпізнано. У такому стані можна виконувати усі дії з API, які потрібні для завершення розпізнавання користувача. ПІсля того, як розпізнавання буде пройдено, можна призначити ще два додаткових рівні: необмежений, який надає повний доступ до усіх дій з API, та обмежений, який надає доступ лише до читання.
Адміністратори системи можуть встановлювати права доступу для уповноважених з’єднань. Для кожного виклику програмного інтерфейсу у libvirt передбачено набір прав доступу, відповідність яких встановлюється за об’єктом, який використовується. Наприклад, Користувач A хоче змінити параметр у об’єкті домену. Коли користувач спробує зберегти внесені зміни, метод virDomainSetSchedulerParametersFlags виконає перевірку того, чи має клієнт права доступу для запису до об’єкта домену. Також може бути виконано додаткові перевірки та використано додаткові параметри доступу. Крім того, може бути виконано фільтрування для того, щоб визначити, які клієнти мають права доступу і до яких об’єктів, що забезпечує кращі можливості з адміністрування прав доступу. Документацію щодо керування доступом polkit можна знайти на сторінці http://libvirt.org/aclpolkit.html.
За встановлення прав доступу відповідає файл налаштувань libvirtd.conf. Для вмикання встановлення прав доступу у цьому файлі використовується параметр access_drivers. Зауважте, що якщо визначено декілька драйверів керування доступом, для надання прав доступу користувачеві доведеться пройти перевірку усіма цими драйверами.
Докладнішу інформацію можна знайти на сторінках https://fedoraproject.org/wiki/Changes/Virt_ACLs та http://libvirt.org/acl.html

2.4.3. Знімки віртуальних машин virt-manager

Засіб Керуванян віртуальними машинами або virt-manager надає змогу спростити керування та спостереження за знімками віртуальної машини для гостьових операційних систем KVM. Зауважте, що для створення знімка virt-manager призупинятиме роботу гостьової віртуальної машини на декілька секунд. Докладнішу інформацію можна отримати за такими адресами:
http://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
http://fedoraproject.org/wiki/Features/Virt_Live_Snapshots
http://libvirt.org/formatsnapshot.html
Розділ щодо знімків у man 1 virsh
http://fedoraproject.org/wiki/QA:Testcase_Virt_Snapshot_UI

2.4.4. Робота у мережі, визначена програмним забезпеченням Ryu

До складу Fedora 20 включено Ryu, програмне забезпечення, яке уможливлює ефективну, керовану програмним забезпеченням роботу у мережі для віртуалізації OpenStack. Як складова частина контролера OpenFlow Ryu забезпечує ізольовану мережу шару 2 у Openstack.

2.5. Сервери баз даних

2.5.1. MongoDB

MongoDB оновлено до версії 2.4. У цій версії реалізовано повнотекстовий пошук, підтримку ширшого масиву індексів геопозиціювання та покращено захист. Щоб дізнатися більше про нову версію, ознайомтеся з нотатками щодо випуску за адресою http://docs.mongodb.org/manual/release-notes/2.4/.

2.5.2. Hadoop

До складу Fedora 20 включено все більш популярну платформу Hadoop та багато пов’язаних з нею пакунків. Докладніший опис можливостей Hadoop у Fedora можна знайти на сторінці https://fedoraproject.org/wiki/Changes/Hadoop.
Пакунки платформи Hadoop є наслідком роботи Fedora Big Data SIG. Знайти дані щодо цієї Special Interest Group можна на сторінці https://fedoraproject.org/wiki/SIGs/bigdata. Ця сторінка допоможе вам у користуванні результатами роботи проекту та надасть можливість взяти участь у подальшій роботі групи.

2.6. Поштові сервери

2.6.1. Типово не встановлюється sendmail

У складі типового переліку пакунків Fedora 20 більше немає засобу для надсилання пошти. До складу попередніх випусків Fedora було включено sendmail, еле ця програма доволі малокорисна без налаштовування вручну.

2.7. Samba

2.7.1. У SSSD додано прив’язку ідентифікаторів до спільних ресурсів CIFS

Докладний опис цієї можливості можна знайти у розділі Безпека.

2.8. Фонові служби системи

2.8.1. Syslog вилучено з типового комплекту для встановлення

syslog більше не є частиною типового набору пакунків. У переважній більшості випадків його функції з журналювання може виконувати journald або, що навіть краще, syslogd.
Користувачам, які звикли шукати журнали системи у /var/log/messages, доведеться звикати до користування journalctl.
Приклади команд journalctl
нова команда journalctlстара команда
journalctlless /var/log/messages
journalctl -ftail -f /var/log/messages
journalctl --unit named.servicegrep named /var/log/messages
journalctl -bПоказує журнал поточного завантаження, не має еквівалентів.

2.8.2. systemd

2.8.2.1. Новий тип модулів: Scope
У новій версії systemd передбачено два нових типи модулів, scope та slice.
Модулі scope автоматично створюються systemd на основі даних щодо наявних процесів. Групування процесу та його дочірніх підпроцесів у модулі scope надає змогу впорядковувати процеси, застосовувати модулі resource або завершувати роботу усієї групи процесів. Сеанси користувачів є одним з прикладів процесів, що містяться у одному модулі scope.
Модулі slice використовуються для групування модулів, які керують процесами, у ієрархію, за допомогою якої можна керувати ресурсами, що надаються окремим модулям slice. Типовими модулями slice є machine.slice для віртуальних машин та контейнерів; system.slice для процесів системи та user.slice для сеансів користувачів. Списки цих типових модулів slice заповнюються автоматично.
Модулі екземплярів, наприклад getty@.service, створюються за потреби на основі шаблона, визначеного у файлі налаштувань. Кожному типу шаблона надається підзріз system slice, у якому міститимуться екземпляри процесу.
Модулі scope та service, пов’язані зі slice є потомками цього вузла slice у ієрархії груп керування. Назва модуля slice описує його позицію щодо кореневого модуля root. Нижче наведено приклад: user-1000.slice є дочірнім модулем user.slice, який у свою чергу є дочірнім модулем ., кореневого модуля slice. Далі, кожен сеанс міститься у модулі scope модуля slice користувача.
	    systemctl status user.slice

  Loaded: loaded (/usr/lib/systemd/system/user.slice; static)
  Active: active since Sun 2013-09-08 01:23:40 MDT; 18h ago
    Docs: man:systemd.special(7)
  CGroup: /user.slice
          ├─user-1000.slice
          │ ├─session-21.scope
          │ │ ├─9226 sshd: pete [priv]
          │ │ ├─9229 sshd: pete@pts/4
          │ │ ├─9230 -bash
          │ │ ├─9262 sudo su -
          │ │ ├─9270 su -
          │ │ ├─9271 -bash
          │ │ └─9509 screen -R
          │ ├─session-18.scope
          │ │ ├─ 7939 sshd: pete [priv]
          │ │ ├─ 7942 sshd: pete@pts/0
          │ │ ├─ 7943 -bash
          │ │ ├─ 7982 sudo su -
          │ │ ├─ 7988 su -
          │ │ ├─ 7989 -bash
          │ │ ├─ 8206 SCREEN
          │ │ ├─ 8207 /bin/bash
          │ │ ├─ 8237 /bin/bash
          │ │ ├─ 8486 less NEWS
          │ │ ├─ 8489 /bin/bash
          │ │ └─10637 systemctl status user.slice
          ## truncated ##

Служби можна додавати до модуля slice за допомогою директиви Slice=назва slice у відповідному файлі налаштувань модуля. Аргументи, за допомогою яких можна обмежувати ресурси у модулі slice або service, описано у man systemd.directives. Див. також man systemd.slice і man systemd.cgroup.
2.8.2.2. systemd-cryptsetup для TrueCrypt
Підтримку TrueCrypt у Fedora розширено підтримкою systemd-cryptsetup для реалізації технології, що спрощує розпізнавання користувачів під час завантаження системи.
2.8.2.3. Фільрування за станом модулів за допомогою systemctl
У новій версії systemctl передбачено підтримку фільтрування списку модулів за станом завантаження. Параметр --state приймає будь-яка значення або список значень, відокремлених комами, станів LOAD, SUB та ACTIVE. Приклад:
	   systemctl --state failed 

2.8.3. journald

2.8.3.1. Перегляд журналу певного сеансу завантаження
У новій версії journalctl можна скористатися для перегляду журналу певного завантаження. Наприклад, щоб переглянути журнал поточного завентаження, віддайте команду:
	  journalctl -b
Переглянути журнал попереднього завантаження:
	  journalctl -b -1
Окрім відносної послідовності завантаження, journald призначає кожному завантаженню 128-бітовий ідентифікатор, за яким можна посилатися на це завантаження. Приклад:
	  journalctl -b 38fd9c3303574ed38e822233457f6b77
2.8.3.2. Посилання на записи журналу за ідентифікатором (cursor)
journalctl може виконувати пошук у вмісті журналу за ідентифікатором запису, відомим як cursor. Подібно до хеш-коду у git, cursor унікальним чином вказує на пункт журналу.
Якщо ви додасте параметр --show-cursor до запиту до journalctl, у останньому рядку виведених даних міститиметься значення cursor:
	  journalctl -b -u network --show-cursor --since 15:00
	  Sep 08 15:37:59 localhost.localdomain network[4074]: [FAILED]
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking.
	  Sep 08 15:37:59 localhost.localdomain systemd[1]: Unit network.service entered failed state.
	  -- cursor: s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831
Курсором (cursor) можна скористатися для ідентифікації певного місця у журналі у межах ширшого запиту, який надаватиме контекст потрібного вам запису:
	  journalctl -c "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"
Скрипти, які виконують обробку даних, виведених journalctl, можуть зберігати значення cursor і використовувати його під час наступного запуску для продовження обробки з місця, де її було зупинено минулого разу:
	  journalctl --after-cursor "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"