Product SiteDocumentation Site

2. Промени във Fedora за Системни Администратори

2.1. Инсталиране

2.1.1. Поддръжка на LVM Thin Provisioning в Anaconda

Инсталаторът на Fedora сега поддържа създаване на thin provisioned LVM томове както в графичния интерфейс, така и в автоматично kickstart инсталиране. Тази промяна включва нов вариант на автоматично разделяне, както и нови опции за създаване на thin томове при разделяне от потребителя.

2.1.2. Безверсийни docdirs

Документация към пакети сега се инсталира в универсални /usr/share/doc/packagename директории. Преди имената на директориите съдържаха номерацията на версията на пакетите като допълнение към името на пакета.

2.2. Сигурност

2.2.1. FreeIPA придоби transitive trust поддръжка

FreeIPA 3.3.2 добавя поддръжка за сложни Active Directory дървета, съдържащи множество домейни. Потребителите от множество AD домейни могат да имат достъп до ресурси във FreeIPA. FreeIPA администраторите могат избирателно да блокират достъпа на всеки от AD домейните.

2.2.2. SSSD добавя ID mapping за CIFS споделяния

System Security Services Daemon във Fedora 20 получи поддръжка на mapping между Windows SIDs и POSIX IDs. Администраторите, използващи в мрежите си SSSD могат да осъществяват контрол на достъпа, използвайки два нови инструмента, setcifsacl и getcifsacl.
Повече информация може да намерите в създадения от ъпстрийма документ на https://fedorahosted.org/sssd/wiki/DesignDocs/IntegrateSSSDWithCIFSClient и в man страниците на setcifsacl, getcifsacl и другите, свързани със SSSD пакети.

2.2.3. Споделени инструменти за системни сертификати

Функционалността Shared System Certificate във Fedora бе подобрена в това издание с добавянето на приложението p11-kit-trust. This package allows modification to trust anchors and blacklist keys and certificates. С една команда администраторите могат да направят промени в тяхната системна база данни за сертификати, вместо да добавят файл в специална директория и да стартират специална команда. Този нов инструмент продължава развитието на Shared System Certificate функционалността.

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

2.3.1. SSD кеширане за блокови устройства

Fedora 20 предлага експериментална поддръжка за добавяне на solid state (SSD) устройства като бърз, прозрачен кеш за традиционните въртящи се дискове (HDD). Файловите системи на SSD кешираните блокови устройства предоставят едновременно бързината на SSD и обема на HDD. Тази функционалност може да се използва както с традиционните схеми, така и с LVM работа с дялове.

Правете резервни копия!

Винаги архивирайте данните си преди да правите промени на ниско ниво, като напр. мигриране към bcache устройство. Until tools like blocks are packaged for Fedora, users are advised to implement bcache by creating clean bcache devices and populating their filesystems from a recent backup.

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

2.4.1. ARM емулация на x86 хостове

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

2.4.2. Контрол на достъпа в Libvirt клиента

libvirt клиентът позволява задаване на правила за позволения, които може да се приложат към всички управлявани обекти и API операции, позволявайки за всички клиентски връзки да бъдат ограничени до малък брой правила и привилегии. Има три нива на достъп, които може да бъдат присвоени.
Unauthenticated достъп се ползва първоначално за всички връзки. Това състояние позволява всички необходими API операции да осъществят удостоверяване. След успешно удостоверяване, могат да бъдат присвоени още две нива: Unrestricted, което дава пълен достъп до всички API операции, и Restricted, което позволява достъп само за четене.
Системните администратори могат да задават позволяващи правила за удостоверените връзки. Всеки API call в libvirt има комплект от позволения, които се проверяват за всеки използван обект. Например, Потребител A иска да промени параметър в обекта домейн. Когато потребителят се опита да запише промяната, методът virDomainSetSchedulerParametersFlags ще провели дали клиентът има право за запис върху обекта домейн. Също така, могат да бъдат обработвани и допълнителни проверки и настройки за позволения. Може да се прави филтриране и по това, кои клиенти върху кои обекти имат позволения, което позволява по-гъвкаво администриране на позволенията. Документация за polkit access control може да намерите на http://libvirt.org/aclpolkit.html.
Конфигурационният файл libvirtd.conf е отговорен за определянето на позволенията за достъп. За тази цел, той използва параметрите access_drivers. Имайте предвид, че ако се изискват повече от един access driver, всички трябва да са успешни за да се предостави достъп.
Повече информация може да намерите на https://fedoraproject.org/wiki/Changes/Virt_ACLs and http://libvirt.org/acl.html

2.4.3. Virt-manager снимки

Virtual Machine 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
Секцията Snapshot в man 1 virsh
http://fedoraproject.org/wiki/QA:Testcase_Virt_Snapshot_UI

2.4.4. Ryu Софтуерно дефинирана мрежа

Fedora 20 представя Ryu, софтуер, предоставящ ефективна, софтуерно дефинирана работа в мрежа за OpenStack виртуализация. As a building block of an OpenFlow controller, Ryu предоставя Layer 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. Ще намерите тази Специална група по интереси-SIG на https://fedoraproject.org/wiki/SIGs/bigdata, вашата врата към използването и участието в предизвикателството.

2.6. Пощенски сървъри

2.6.1. Няма по подразбиране sendmail

Fedora 20 вече не съдържа по подразбиране сървър за пренасяне на поща. Предишните издания на Fedora включваха sendmail, но той има ограничена функционалност без допълнително ръчно конфигуриране.

2.7. Samba

2.7.1. SSSD добавя ID mapping за CIFS споделяния

Информация за тази функционалност може да намерите в секцията Security.

2.8. Системни Демони

2.8.1. Syslog е премахнат от подразбиращата се инсталация

syslog вече не е включен в инсталациите по подразбиране. journald предоставя по-широка употреба или пък по-добра работа от syslogd.
Потребителите, свикнали да поглеждат /var/log/messages за системните съобщения, вече ще трябва да използват journalctl.
Примери за командата journalctl
ново journalctlстаро messages
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. Нови unit типове: Scope
Systemd сега има два нови unit типа, scope и slice.
scope unit-ите автоматично се създават от systemd от съществуващите процеси. Чрез групиране на процес и неговите дъщерни, scope unit може да се използва за организирането им, прилагане на resource units, или прекратяване на група процеси. User sessions са един пример на процеси, съдържащи се в scope unit.
slice unit-ите - управление на йерархични процеси, при което може да се контролират ресурси, групирани в резени. Резените по подразбиране са machine.slice, за виртуални машини и контейнери; system.slice, за системни услуги; и user.slice, за потребителски сесии. Тези резени по подразбиране се създават автоматично.
Instance units, като getty@.service, се зареждат по поръчка като се използват шаблоните, дефинирани в техния конфигурационен файл. Each type of template is given a subslice of the system slice, and instances are contained within that slice.
Scope and service units assigned to a slice are descendants of that slice's node in the control group tree. A slice's name describes its position relative to the root slice. The output below demonstrates how user-1000.slice is a child of user.slice, which is in turn a child of ., the root slice. Each session is further confined in a scope unit within the user's 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=slicename в техния конфигурационен файл. Аргументите, позволяващи ограниченията на ресурси в резен или service unit са описани в man systemd.directives. Вижте също man systemd.slice и man systemd.cgroup.
2.8.2.2. systemd-cryptsetup за TrueCrypt
Поддръжката за TrueCrypt във Fedora е разширена от systemd-cryptsetup поддръжка за технологията, позволявайки лесно удостоверяване по време на зареждането.
2.8.2.3. Филтриране по unit state със systemctl
systemctl now supports filtering the unit list output by load state. The --state option will accept any value or a comma-separated list of the values of LOAD, SUB, or ACTIVE states. For example,
	   systemctl --state failed 

2.8.3. journald

2.8.3.1. Преглед на записите от определено зареждане
journalctl сега може да се използва за преглед на записите от конкретно зареждане. Например, за да видите записите от текущото:
	  journalctl -b
Или, за да видите тези от предишното:
	  journalctl -b -1
В допълнение на задаването на зареждане с отместване, journald присвоява 128-битов boot ID, който може да бъде посочен. Например:
	  journalctl -b 38fd9c3303574ed38e822233457f6b77
2.8.3.2. Справки от журнала чрез курсори
journalctl може да покаже съдържанието на журнала, отбелязано с идентификатор на запис, наречен cursor. Подобно на git hash, cursor е уникален идентификатор на точка в журнала.
Ако добавите --show-cursor към journalctl запитването, последният ред от показаното ще съдържа стойността на курсора:
	  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
The cursor can be used to identify that point in the journal in a broader query to provide context:
	  journalctl -c "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"
Scripts parsing journalctl's output can store the cursor value and use it on their next run to pick up where they left off:
	  journalctl --after-cursor "s=13497722134642a2ac1544bada0c8836;i=1120d;b=8491c05dabd3444ca122e7069b5de0a9;m=db2118a46;t=4e5e7d81c7402;x=d177768ac95df831"