Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Content (107 страница со старыми записями)

Новости управления сетью

Это архивная статья

Наш коллега, инженер Rackspace, Major Hayden, которого вы можете уже знать, как человека с самым прекрасным в мире резюме, разразился серией статей о том, как использовать systemd-networkd (с небольшим перекосом на тему Rackspace, где Fedora всегда была доступна) - использование systemd-networkd в серверах Rackspace OnMetal, как устроены предсказуемые названия сетевых интерфейсов в systemd, и как смастерить сетевой роутер с помощью systemd-networkd (у нас есть некоторые замечания по поводу именно этой заметки, но в целом там все хорошо).

Постепенно развивается flannel. В версии 0.5.0 исправили гадкую ошибку в наиболее скоростном режиме работы, т.е. VxLAN, когда терялся самый первый пакет, добавили поддержку Google's Compute Engine, добавили возможность создавать несколько сетей, и добавили интересную возможность клиент-серверного режима работы.

В версии 0.5.1 добавили socket activation для клиент-серверного режима. В версии 0.5.2 добавили возможность работы за NAT. А в недавно вышедшей `версии 0.5.3 <>`__ его полностью привели к пока еще секретному стандарту CNI, о котором мы вам по секрету-же уже сообщили.

В компании Docker Inc тоже решили поработать над своими сетевыми проблемами, и в начале лета анонсировали SDN-плагин.

В стотыщепятисотый раз скажем, что SDN, это уже не будущее, это настоящее. На технологию возлагаются большие надежды в сотовых сетях следующих поколений (если вы были на прошедшем Red Hat Forum 2015 в Москве, те могли слышать интересные новости во время выступления нашего товарища, Jan Wildeboer). Интересно, что компания VMware очень серьезно настроена на SDN/NFV-систему на базе OpenStack (или наоборот). Время проприетарных решений уходит, и видимо они вовремя заметили запросы на стандартное открытое решение.

С ростом интереса к SDN и сложным сетевым решениям, в полный рост стали видны проблемы производительности сети (которые возникают порой в довольно неожиданных местах).

Системы должны справляться просто с диким объемом пакетов, приходящих на огромной скорости. В Red Hat работа ведется с двух сторон. Во-1 разгоняется сетевая подсистема ядра, что будет заметно даже обычным десктопным пользователям. А во-2 разгоняется весь вертикальный стек управления трафиком.

Тут плюсы увидят, наверное, лишь производители и разработчики SDN-систем.

И о грустном. Из РФ эвакуировали еще один офис. Компания F5, разработчик SDN для OpenStack, о которой мы мельком упоминали, приняла решение о срочной перевозке всего томского офиса в США. Жаль, конечно. Еще на несколько специалистов в РФ меньше.

Docutils System Messages

System Message: ERROR/3 (<string>, line 77); backlink

Anonymous hyperlink mismatch: 1 references but 0 targets. See "backrefs" attribute for IDs.

GCC переходит на Git и другие новости.

Наконец-то, GCC начал переход на Git с Subversion! Вот этого реально давно ждали!

Из других новостей - наш коллега, инженер Red Hat, Carlos O'Donell, объявил о выходе Glibc 2.22 (уже перевели на русский). К сожалению, после прочтения анонса складывается впечатление, что после Glibc 2.20, где объявили о слиянии с Eglibc (прощай, Eglibc, нам будет не хватать веселья), народ не очень желает "пиарить" процесс разработки. Непонятно, то ли subversion являлся одной из характерных черт этого закрыто-открытого процесса, но ведь и правда о новостях Glibc / GCC слышно как-то немного. На линукс-сайтах пишут по результатам пресс-релизов, а на пульсе проекта руку никто вроде бы и не держит. А новинок там навалом!

Мы периодическиш пишем о больших новинках базовых компонентов, например, про offloading в GCC, но нашей энергии хватает лишь на те новости, что прямо или косвенно касаются нас или сделаны нашими коллегами. Этого, конечно, мало. Мы всегда призывали участников других коммьюнити читать не только (микро)блоги, но и GitHub, списки рассылок, баг-трекеры, IRC/XMPP-чаты разработчиков - там самая движуха и "эксклюзивные" новости. Например, навскидку про Glibc / GCC за последние полгода:

Вообще, несмотря на необходимую осторожность, количество изменений в базовые компоненты не снижается, и в т.ч. в их инфраструктуру. Самым главным улучшением является удобная VCS (т.е. Git) и тестирование. В GCC тесты уже включают, в Glibc с тестированием не все так однозначно (например, почитайте транскрипт выступления нашего коллеги, бывшего инженера Red Hat, Roland McGrath). Одна из проблем тестирования базовых компонентов, таких, как ядро или Libc, это то, что они слишком уж низкоуровневые. Непросто не только написать юнит-тесты, но и тестировать установленную копию. Изолироваться тут не получается, кроме как в виртуальной машине. А там может быть непросто воспроизвести ситуацию, приводящую к ошибке (но, кстати, тем ценнее инструкции по тому, как тестировать с помощью systemtap наживую).

Ну и из изменений в Fedora - наконец-то локали в Glibc будут упакованы отдельно (померяйте размер /usr/lib/locale, если кто-то сомневается, зачем это нужно). Раньше для этого, как вариант, приходилось указывать флаги для rpm где-нибудь в /etc/rpm/macros.locales.

Вторая новость, это расставание Fedora с давно устаревшей библиотекой librtkaio.

И наконец, не совсем про базовые компоненты (хотя кому как) - Vim тоже перешел на GitHub (и на Git с Mercurial). Все-таки как хорошо, что Google Code закрывается!

/images/mercurial_user.png
**Пользователь Mercurial недоволен переходом GCC на Git и отказом Vim

System Message: WARNING/2 (<string>, line 87); backlink

Inline strong start-string without end-string.

от Mercurial**

Daniel Stenberg собрал статистику использования клавиатуры

Daniel Stenberg, наш хороший знакомый, с которым мы теперь регулярно видимся на FOSDEM, и инженер Mozilla Foundation, год назад добровольно установил кейлоггер на свой рабочий компьютер.

Конечно, он его использовал не так, как обычно используют в Windows и Mac OS X, где с помощью кейлоггеров обворовывают и так обделенных пользователей этих проприетарных операционных систем, а для сбора статистики. И теперь он проанализировал ее и опубликовал результаты.

Оказалось, что за год он сделал почти 7 миллионов нажатий, что в среднем дало почти 2000 нажатий на условный рабочий час. Но были и более плодотворные рабочие часы. Например, однажды кейлоггер насчитал 8842 нажатия в час, а это ведь за 3600 секунд, если кто не пересчитал сразу в уме! А за самый продуктивный день он сделал 63757 нажатия.

**Что будем делать? Завидовать будем!** И не только завидовать, но и стремиться к результатам старших товарищей!

Еще один проект, продолжающий дело OLPC

Это архивная статья

Дружественная нам организация, One Laptop Per Child, благодаря которой Fedora одно время была самым массовым Linux-дистрибутивом, предустанавливаемым на ноутбуки (до того, как появился Chromebook) может и отошла на покой, но дело ее живет! Вы помните, в начале прошлого года будущее OLPC представлялось скорее негативно, но люди-то, зараженные идеями компьютеризации третьего мира, остались, и вскоре появился проект Endless PC, о котором вы уже слышали. А вот на днях появился еще один проект - One Education, созданный бывшим австралийским филиалом OLPC. К сожалению, они полностью перешли на Android, и с нашей точки зрения, это ошибка. Все-таки Android больше рассчитан на потребление контента (это такой интернет-телевизор), в отличие от полноценной Linux-системы, Sugar OS, но учитывая, что их поджимали сроки, это решение вполне объяснимо. В этом смысле Endless PC выглядит поинтереснее, но пускай так.

image0**Пусть расцветают сто цветов, пусть соперничают сто школ!**

Проброс USB в виртуалку по сети средствами usbredir и qemu

Это архивная статья

Есть интересная и довольно прибыльная задача - пробрасывать физические USB-устройства в виртуальную машину с Windows, так, чтобы та считала, что они подключены непосредственно к ней. Некоторые используют проприетарные и глючные продукты для ее решения, но на самом деле стоит попробовать открытый и надежный продукт нашего коллеги, Hans de Goede - usbredir. С его помощью можно как раз пробросить [STRIKEOUT:USB-ключ для 1С] произвольное USB-устройство в виртуалку. Отрадно, что появляются хаутушки по этой теме:

Проброс USB в виртуалку по сети средствами usbredir и qemu

image0 На сегодняшний день существет довольно много способов пробросить USB-устройство на другой компьютер или виртуалку по сети.

Из наиболее популярных — железячные такие как AnywhereUSB и чисто програмные продукты, из тех что я попробовал сам: USB Redirector и USB/IP.

Я бы хотел рассказать вам еще об одном интересном способе, который работает непосредственно с эмулятором qemu.

Он так же является частью проекта spice, официально поддерживаемым RedHat.

usbredir, это открытый протокол для проброса usb-устройств по tcp на удаленный виртуальный сервер, разработанный при поддержке RedHat в рамках проекта spice. Но как оказалось им можно вполне успешно пользоваться и без spice. В роли сервера выступает usbredirserver, который шарит usb-устройство на определенный порт, а в качестве клиента сам qemu, который эмулирует подключение экспортированного usb-устройства в определенный usb-контроллер вашей виртуальной машины. Благодаря такому подходу в качестве гостевой системы может использоваться абсолютно любая ОС, так как она даже не знает, что устройство является проброшенным удаленно, а вся логика ложится на qemu. ` <>`__ .. rubric:: Для начала несколько слов о вышеперчисленных решениях

System Message: ERROR/3 (<string>, line 61)

Unexpected indentation.
name: для-начала-несколько-слов-о-вышеперчисленных-решениях
  • AnywhereUSB — довольно неплохое решение, но дорогое, и имеет неприятние глюки, например бывает если расшаренная флешка отваливается, то переподключить ее обратно можно только физически вынув и вставив ее.
  • USB/IP — OpenSource проект. Вроде как был заброшен. По факту глючит довольно сильно. При разрыве соединения, машина частенько уходит в полнейший freezee, а windows показывает BSOD
  • USB Redirector — Замечательная софтина. Для расшаривания устройств с linux на linux бесплатна, во всех остальных случаях уже стоит денег, не так много как AnywhereUSB, но и не бесплатно как хотелось бы :)

Как видно есть из чего выбрать, но давайте же наконец попробуем еще один способ — usbredir? .. rubric:: Настройка виртуальной машины

System Message: ERROR/3 (<string>, line 79)

Unexpected indentation.
name: настройка-виртуальной-машины

Для того что бы было куда подключать экспортированные устройства, на виртуальной машине нужно создать необходимые usb-контроллеры:

  • uhci — для USB1.0
  • ehci — для USB2.0
  • xhci — для USB3.0

Для qemu (без libvirt)

Скачайте конфиг ehci-uhci.cfg, положите его в /etc/qemu/

$ curl https://cgit.freedesktop.org/spice/qemu/plain/docs/ich9-ehci-uhci.cfg --create-dirs -o /etc/qemu/ehci-uhci.cfg

И добавьте следующие опции в команду запуска виртуальной машины:

-readconfig /etc/qemu/ich9-ehci-uhci.cfg
-chardev spicevmc,name=usbredir,id=usbredirchardev1
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3
-chardev spicevmc,name=usbredir,id=usbredirchardev2
-device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,debug=3
-chardev spicevmc,name=usbredir,id=usbredirchardev3
-device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=3

Для libvirt

Можно использовать такой конфиг.

В исходном файле конфигурации виртуальной машины в узле <devices> удаляем все USB контроллеры и добавляем следущий блок:

<controller type='usb' index='0' model='ich9-ehci1'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
<master startport='0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci2'>
<master startport='2'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci3'>
<master startport='4'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/>
</controller>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='3'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='4'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='5'/>
</redirdev>
<redirdev bus='usb' type='spicevmc'>
<address type='usb' bus='0' port='6'/>
</redirdev>

Но у меня он почему-то не заработал, и я решил пойти другим путем, а именно явно указть libvirt с какими опциями запускать qemu: Этот блок рамещается перед тегом </domain>:

<qemu:commandline>
<qemu:arg value="-readconfig"/>
<qemu:arg value="/etc/qemu/ich9-ehci-uhci.cfg"/>
<qemu:arg value="-chardev"/>
<qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev1"/>
<qemu:arg value="-device"/>
<qemu:arg value="usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3"/>
<qemu:arg value="-chardev"/>
<qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev2"/>
<qemu:arg value="-device"/>
<qemu:arg value="usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3"/>
<qemu:arg value="-chardev"/>
<qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev3"/>
<qemu:arg value="-device"/>
<qemu:arg value="usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"/>
</qemu:commandline>

Не забудьте так же скачать конфиг ehci-uhci.cfg, и сохранить его в /etc/qemu/ как в случае с qemu без libvirt Кстати, после данной настройки, если вы используете spice, станет возможен проброс usb-устройств с клиента spice на сервер.

Заводим виртуалку, теперь все готово для осуществления проброса.

Запуск сервера

Пакет usbredirserver можно найти в стандартных репозиториях практически во всех популярных дистрибутивах linux.

Вставляем флешку в компьютер, смотрим вывод usb-устройств:

$ lsusb
...
Bus 003 Device 011: ID 125f:c82a A-DATA Technology Co., Ltd.
...

Видим что пара vendorid:prodid равна 125f:c82a, а ядро определило флешке 003-001 usbbus-usbaddr соотвественно.

Теперь давайте расшарим ее на 4000 порт:

# Используя пару vendorid:prodid
$ usbredirserver -p 4000 125f:c82a
# Используя пару usbbus-usbaddr
$ usbredirserver -p 4000 003-011

Подключение устройства к виртуальной машине

Заходим на гипервизор и в qemu-monitor нашей машины выполняем следующие команды:

# Добавляем наше устройство
chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123
# Подключем его в ehci контроллер (USB-2.0)
device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4

Что бы отключить флешку достаточно такой команды:

device_del usbredirdev1

Если у вас libvirt, то команды в qemu-monitor можно отправить следующим образом:

$ virsh qemu-monitor-command --hmp one-73 'chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123'
$ virsh qemu-monitor-command --hmp one-73 'device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4'
$ virsh qemu-monitor-command --hmp one-73 'device_del usbredirdev1'

На этом все, после данных шагов ваша ВМ увидит вашу флешку и сможет с ней нативно работать.

Если устройств много и все они одинаковые

Вот тут появилась интересная задачка, как пробросить несколько одинаковых девайсов на разные ВМ? При этом, стоит отметить, все устройства имеют одинаковую пару vendorid:prodid, а пара usbbus-usbaddr совсем не постоянна, стоит только вынуть и вставить устройство, так оно сразу поменяет свой usbaddr.

Для себя я решил ее при помощи udev, и небольшого скрипта.

Кстати если вы не совсем понимаете как работает udev, на Debian Wiki есть классная статья о udev И так приступим: Для начала узнаем серийник нашего устройства, по которому и будем идентифицировать его в udev:

$ udevadm info -a -n /dev/bus/usb/003/011 | grep '{serial}'
    ATTR{serial}=="11C130317234004B"
    ATTRS{serial}=="0000:00:14.0"

Теперь создадаим файл /etc/udev/rules.d/99-usb-serial.rules и запишем в него следующее правило:

SUBSYSTEM=="usb", ATTRS{idVendor}=="125f", ATTRS{idProduct}=="c82a", ATTR{serial}=="11C130317234004B", SYMLINK+="usbdevices/token1"

Перезагрузим udev-правила:

$ udevadm control --reload-rules

Теперь, при подключении нашей флешки, в /dev/usbdevices/token1 на нее появится симлинк.

Я написал небольшой скрипт, который использует этот симлинк, для того что бы узнать настоящую пару usbbus-usbaddr устройства и расшарить его на нужный порт usbredirserver-by-symlink.sh

#!/bin/bash
keys="${@:1:${#}-1}"
usblink="${@: -1}"
if [ -L $usblink ] && [ $# != 0 ]; then
    usbbus=`udevadm info -a -n $usblink | awk -F== '/ATTR{busnum}/ { gsub(/"/,"",$2);print $2 }'`
    usbaddr=`udevadm info -a -n $usblink | awk -F== '/ATTR{devnum}/ { gsub(/"/,"",$2);print $2 }'`
    if [ "$usbbus" != "" ] && [ "$usbaddr" != "" ]; then
        usbredirserver $keys $usbbus-$usbaddr
    else
        echo "This is not usb device"
        exit 1
    fi
else
    echo "Usage: usbredirserver-by-symlink.sh [-p|--port <port>] [-v|--verbose <0-5>] /dev/usbdevice"
    exit 1
fi

К сожалению от смены пары usbbus-usbaddr после расшаривания устройства этот скрипт не спасет, так как usbredirserver не отваливается, если устройство вынуть или если такое устройство вообще не существует. Но он облегчит путь и поможет не запутаться при расшаривании нужного устройства на нужные ВМ.

В дальнейшем его можно будет использовать, для написания следующего скрипта, который будет мониторить подключение/отключение устройств, расшаривать нужные и автоматически подключать/отключать их на удаленной ВМ.

Источники:

umvirt.ru/node/82 opennebula.org/opennebula-for-virtual-desktops opennet.ru/opennews/art.shtml?num=30773 lists.gnu.org/archive/html/qemu-devel/2013-07/msg05244.html

GNOME и будущее поддержки железа

На наших глазах развивается драма, разгоревшаяся после предложения нашего коллеги, Christian Schaller, рекомендовать конечным пользователям использовать LibreOffice вместо AOO.

Christian адресовал предложение смотрителям кладбища OpenSource-проектов, Apache Software Foundation, так что история получилась еще смешнее. Драма уже обсуждается коллегами-аналитиками на русскоязычных ресурсах - OpenNET.ru и Linux.org.ru.

По существу вопроса добавить наверное нечего - каждому, кто заглянет в git log обоих проектов, будет все ясно. Но особенно интересна и показательна типичная реакция некоторых коллег-аналитиков - "в вашем %имя_проекта% полно глюков, и документы открываются/сохраняются/отображаются неправильно, но я вам устранить эту ошибку помогать не буду, а буду ждать, пока ею займется кто-то другой".

Нам кажется такая позиция неконструктивной и не только чуждой самому духу сообщества открытого ПО, но и серьезно мешающей бизнес-процессу в конкретных компаниях. Как положительный пример отношения к проблемным моментам, хочется обратить внимание на доклад другого нашего коллеги, Bastien Nocera, на недавно прошедшей конференции GUADEC 2015.

Bastien Nocera рассказал о своем опыте запуска Linux на дешевом Windows-планшете и заодно предложил новый способ работы GNOME с новым оборудованием - чтобы было так просто, как и с Android.

Половину своего выступления Bastien рассказывал то, как вообще можно сферически запустить сферический Linux (а потом и GNOME) на новом сферическом устройстве. А вот под конец, он вернулся к началу и изложил события ровно в том порядке, в котором они произошли в реальности (с гораздо меньшим успехом). Но, как он подчеркнул, более успешная версия событий вполне достижима, если внести немного изменений в GNOME.

https://lwn.net/images/2015/08-guadec-nocera-sm.jpg

История началась, когда Bastien купил дешевый китаепланшет, и решил поставить туда операционную систему GNOME вместо Windows 8. Главной проблемой был неработающий WiFi. В планшете был чип от Realtek, и Bastien даже сумел получить к нему исходники от компании, но они были в ужасном состоянии.

Скорее всего исходники были от драйвера для Android, но с мэйнстримовым Linux-ядром они не работали. Покопавшись в исходниках он обнаружил, что они забиты бесполезным мусором - тестами, кодом для препродакшен-версий оборудования, и т.д. В драйвере был даже какой-то код для USB, т.к. wifi был физически подключен к материнской плате через USB. В конечном итоге, с помощью других программистов, среди которых были и наши коллеги, он сумел выкинуть лишнее, и кодовая база уменьшилась в 20 раз.

Затем они привели его в состоянии пригодности для работы со стандартным ядром. Это заняло время, но все заработало, и после того, как получившийся код был выложен на GitHub on начал работу над следующей задачей. Следующим он добился работоспособности USB On-The-Go, что позволило подключиться к планшету через USB. Это, в свою очередь, позволило ему использовать Android Debug Bridge (adb), чтобы контролировать и мониторить процесс загрузки. Для этого пришлось поправить adb-демон, чтобы он работал с glibc и systemd, вместо Bionic и init из Android. Пропатченный adb он также выложил на GitHub.

Тут уже он настроил "EFI mixed mode" (загрузка 64-битного ядра 32-битным firmware), а позже он заменил загрузчик на GRUB, настроил Secure Boot shim, и запустил инсталлятор Fedora, чтобы установить полноценную 64-битную Linux-систему. ADB позволяет загружать пакеты на планшет, так что с поддержкой его в GNOME, разработчики могли бы создавать приложения xdg-app с помощью GNOME Builder на рабочих машинах, загружать их по USB на планшеты и тут же тестировать. Никаких эмуляторов, симуляторов, и не нужно было бы.

Тут то Nocera и остановился, чтобы сообщить, что лишь половина этого всего случилась в реальности. Ну, пока так. Действительно, ему удалось запустить WiFi с помощью Larry Finger. И его работа над ADB и EFI mixed mode тоже существует, хотя не все патчи готовы к включению в апстрим.

То, что он рассказывал, это то, что бы он хотел от GNOME в ближайшее время, и что ему хотелось бы обсудить. Все кусочки уже в наличии - xdg-app может создавать образы, которые, как и apk-файлы для Android, разработчик мог бы попробовать установить и потестировать.

GNOME Builder хорошо бы, чтобы умел создавать пакеты xdg-app, и было бы здорово интегрировать его с adb.

Тут есть и другие проблемы, некоторые совсем не относятся к GNOME.

Windows 8 не поддерживает USB On-The-Go, и поэтому даже если system-on-chip, используемый в планшете, поддерживает USB OTG, производитель может не присоединить его к материнской плате. Одной из альтернатив был бы кабель USB host-to-host - они дешевы, но потребуется некоторая работа, чтобы они надежно работали c Linux-десктопами. Внутри таких коннекторов используются дешевые сетевые адаптеры USB, между которым находится Ethernet-хаб, поэтому поддержка их потребует разработки драйверов.

Гораздо большей проблемой может стать то, что EFI mixed mode пока не полностью подерживается в Linux.

Действительно, уже можно загрузить 64-битный Linux на 32-битном UEFI, но когда драйверы начинают обращаться к UEFI, тогда начинаются проблемы. Ну и проблема еще в том, что дешевые планшеты меняются очень быстро, и поддерживать большое количество моделей будет непросто. Но если на планшет можно установить старую версию Windows, то скорее всего легко получится запустить и Linux.

Nocera закончил выступление объявив, что претензии не принимаются.

Он сказал, что сожалеет, что ему пришлось приврать в первой части доклада, когда он рассказывал про идеализированный сценарий, скрыв, что еще необходимо много работы. Но именно такая поддержка оборудования, это именно то, что нужно для распространения GNOME.

Мобильные устройства никуда не уйдут, и т.к. у Android есть захватывающая история о том, как каждый желающий может подключить UBS-кабель, и начать разрабатывать ПО, которое можно сразу же запустить на любом планшете или телефоне, то GNOME стоило бы обеспечить такой же уровень поддержки.

Хотелось бы обратить внимание, как энергично Bastien решал проблемы, с которыми сталкивался. Конечно, не каждому суждено доработать драйвер для Wi-Fi (даже с помощью старших товарищей), но имеет смысл при возникновении проблемы проконсультироваться с upstream-разработчиками. Скажем, открыть заявку в Bugzilla.

Существующие стратегии по обеспечению безопасности в контейнерах

Это архивная статья

Наш коллега, инженер Rackspace, Major Hayden, также известный, как человек с самым прекрасным в мире резюме, объявил в своем блоге о выходе статьи, в которой он попытался просуммировать существующие подходы к обеспечению безопасности в контейнерах. Автор понимает, что три десятка страниц, это не тот объем, с которым можно претендовать на всеобъемлющее научное исследование, но как старт для более дотошных исследователей - вполне пойдет.

Читайте, присылайте критику.

Очередная обучалка по журналированию в systemd

Это архивная статья

Все больше и больше появляется материалов по systemd! Вот, на днях на известном ресурсе Хабрахабр появилась обучалочка по управлению журналированием в systemd:

Управление логгированием в systemd tutorial

Systemd Journal Демон инициализации systemd де-факто уже стал стандартом в современных Linux-системах. На него перешли многие популярные дистрибутивы: Debian, RHEL/CentOS, Ubuntu (начиная с версии 15.04).

В systemd используется принципиально иной (по сравнению с традиционным инструментом syslog) подход к логгированию.

В его основе лежит централизация: специализированный компонент journal cобирает все системные сообщения (сообщения ядра, различных служб и приложений). При этом специально настраивать отправку логов не нужно: приложения могут просто писать в stdout и stderr, a journal сохранит эти сообщения автоматически. Работа в таком режиме возможна и с Upstart, но он сохраняет все логи в отдельный файл, тогда как systemd сохраняет их в бинарной базе, что существенно упрощает  систематизацию и поиск.

Хранение логов в бинарных файлах также позволяет избежать сложностей с использованием парсеров для разных видов логов. При необходимости логи можно без проблем переконвертировать в другие форматы (более подробно об этом будет рассказано ниже).

Journal может работать как совместно с syslog, так и полностью заменить его.

Для просмотра логов используется утилита journalctl. Об особенностях и тонкостях работы с ней мы расскажем в этой статье.

` <>`__ .. rubric:: Установка времени

System Message: ERROR/3 (<string>, line 57)

Unexpected indentation.
name: установка-времени

Одним из существенных недостатков syslog является сохранение записей без учёта часового пояса. В journal этот недостаток устранён: для логгируемых событий можно указывать как местное время, так и универсальное координированное время (UTC). Установка времени осуществляется с помощью утилиты timedatectl.

Просмотреть список часовых поясов можно при помощи команды:

$ timedatectl list-timezones

Установка нужного часового пояса осуществляется так:

$ timedatectl set-timezone <часовой пояс>

По завершении установки будет нелишним убедиться в том, что всё сделано правильно:

$ timedatectl status
Local time: Thu 2015-07-30 11:24:15 MSK
Universal time: Thu 2015-07-30 08:24:15 UTC
RTC time: Thu 2015-07-30 08:24:15
Time zone: Europe/Moscow (MSK, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a

В самой первой строке (Local time) должны быть показаны точное текущее время и дата.

Journalctl: просмотр логов

Для просмотра логов используется утилита journalctl.

Если ввести команду journalсtl без каких-либо аргументов, на консоль будет выведен огромный список:

-- Logs begin at Wed 2015-07-29 17:12:48 MSK, end at Thu 2015-07-30 11:24:15 MSK. --
Jul 29 17:12:48 host-10-13-37-10 systemd-journal[181]: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).

Jul 29 17:12:48 host-10-13-37-10 systemd-journal[181]: Runtime journal is using 4.0M (max allowed 20.0M, trying to leave 30.0M free of 195.9M available → current limit 20.0M).

Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuset
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpu
Jul 29 17:12:48 host-10-13-37-10 kernel: Initializing cgroup subsys cpuacct
Jul 29 17:12:48 host-10-13-37-10 kernel: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
Jul 29 17:12:48 host-10-13-37-10 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 root=UUID=b67ea972-1877-4c5b-a328-29fc0d6c7bc4 ro console=tty1 console=ttyS0 video=640x480 consoleblank=0 panic=15 c

Здесь мы привели лишь небольшой его фрагмент; на самом деле он включает гигантское количество записей.

Фильтрация логов

У утилиты journalctl есть опции, с помощью которых можно осуществлять фильтрацию логов и быстро извлекать из них нужную информацию.

Просмотр логов с момента текущей загрузки

С помощью опции -b можно просмотреть все логи, собранные с момента последней загрузки системы:

$ journalctl -b

Просмотр логов предыдущих сессий

С помощью journalctl можно просматривать информацию о предыдущих сессиях работы в системе — в некоторых случаях это бывает полезным.

Следует, однако, учитывать, что сохранение информации о предыдущих сессиях поддерживается по умолчанию не во всех дистрибутивах Linux.

Иногда его требуется активировать Для этого нужно открыть конфигурационный файл journald.conf, найти в нём раздел [Journal] и изменить значение параметра storage на persistent:

$ sudo nano /etc/systemd/journald.conf
...
[Journal]
Storage=persistent

Просмотреть список предыдущих загрузок можно с помощью команды:

$ journalctl --list-boots

0 9346310348bc4edea250555dc046b30c Thu 2015-07-30 12:39:49 MSK—Thu 2015-07-30 12:39:59 MSK

Её вывод состоит из четырёх колонок. В первой из них указывается порядковый номер загрузки, во второй — её ID, в третьей — дата и время. Чтобы просмотреть лог для конкретной загрузки, можно использовать идентификаторы как из первой, так и из второй колонки:

$ journalctl -b 0

или

$ journalctl -b 9346310348bc4edea250555dc046b30c

Фильтрация по дате и времени

В journalctl имеется также возможность просмотра логов за определённые периоды времени. Для этого используются опции —since и —until. Предположим, нам нужно просмотреть логи начиная с 17 часов 15 минут 20 июля 2015 года. Для этого потребуется будет выполнить команду:

$ journalctl --since "2015-07-20 17:15:00"

Если с опцией since не будет указано никакой даты, на консоль будут выведены логи начиная с текущей даты. Если дата указана, но при этом не указано время, будет применено значений времени по умолчанию — «00:00:00». Секунды также указывать не обязательно (в этом случае применяется значение по умолчанию — 00).

Можно воспользоваться и вот такими человекопонятными конструкциями:

$ journalctl ---since yesterday
$ journalctl --since 09:00 --until now
$ journalctl --since 10:00 --until "1 hour ago"

Фильтрация по приложениям и службам

Для просмотра логов конкретного приложения или службы используется опция -u, например:

$ journalctl -u nginx.service

Приведённая команда выведет на консоль логи веб-сервера nginx.

Нередко возникает необходимость просмотреть логи какой-либо службы за определённый период времени. Это можно сделать при помощи команды вида:

$ journalctl -u nginx.service --since yesterday

C опцией -u также используется фильтрация по дате и времени, например:

$ journalctl -u nginx.service -u php-fpm.service —since today

Благодаря этому можно отслеживать взаимодействие различных служб и получать информацию, которую нельзя было бы получить при отслеживании соответствующих процессов по отдельности.

Фильтрация по процессам, пользователям и группам

Просмотреть логи для какого-либо процесса можно, указав в команде journalctl его идентификационный номер (PID), например:

$ journalctl _PID=381

Для просмотра логов процессов, запущенных от имени определённого пользователя или группы, используются фильтры _UID и _GID соответственно. Предположим, у нас имеется веб-сервер, запущенный от имени пользователя www-data. Определим сначала ID этого пользователя:

$id -u www-data

33

Теперь можно просмотреть логи всех процессов, запущенных от имени этого пользователя:

$ journalctl _UID=33

Вывести на консоль список пользователей, о которых имеются записи в логах, можно так:

$ journalctl -F _UID

Для просмотра аналогичного списка пользовательских групп используется команда:

$ journalctl -F _GUID

С командной journalctl можно использовать и другие фильтры.

Просмотреть список всех доступных фильтров можно, выполнив команду

$ man systemd.journal-fields

Фильтрация по пути

Просмотреть логи для какого-либо процесса также можно, указав путь к нему, например:

$ journalctl /usr/bin/docker

Иногда таким способом можно получить более подробную информацию (например, просмотреть записи для всех дочерних процессов).

Просмотр сообщений ядра

Для просмотра сообщений ядра используется опция -k или −−dmesg:

$ journalctl -k

Приведённая команда покажет все сообщения ядра для текущей загрузки.

Чтобы просмотреть сообщения ядра для предыдущих сессий, нужно воспользоваться опцией -b и указать один из идентификаторов сессии (порядковый номер в списке или ID):

$ journalctl -k -b -2

Фильтрация сообщений по уровню ошибки

Во время диагностики и исправления неполадок в системе нередко требуется просмотреть логи и выяснить, есть ли в них сообщения о критических ошибках. Специально для этого в journalctl предусмотрена возможность фильтрации по уровню ошибки. Просмотреть сообщения обо всех ошибках, имевших место в системе, можно с помощью опции -p:

$ journalctl -p err -b

Приведённая команда покажет все сообщения об ошибках, имевших место в системе.

Эти сообщения можно фильтровать по уровню. В journal используется такая же классификация уровней ошибок, как и в syslog:

  • 0 — EMERG (система неработоспособна);
  • 1 — ALERT (требуется немедленное вмешательство);
  • 2 — CRIT (критическое состояние);
  • 3 — ERR (ошибка);
  • 4 — WARNING (предупреждение);
  • 5 — NOTICE (всё нормально, но следует обратить внимание);
  • 6 — INFO (информационное сообщение);
  • 7 —DEBUG (отложенная печать).

Коды уровней ошибок указываются после опции -p. .. rubric:: Запись логов в стандартный вывод

System Message: ERROR/3 (<string>, line 329)

Unexpected indentation.
name: запись-логов-встандартный-вывод

По умолчанию journalctl использует для вывода сообщений логов внешнюю утилиту less. В этом случае к ним невозможно применять стандартные утилиты для обработки текстовых данных (например, grep).

Эта проблема легко решается: достаточно воспользоваться опцией −−no-pager, и все сообщения будут записываться в стандартный вывод:

$ journalctl --no-pager

После этого их можно будет передать другим утилитам для дальнейшей обработки или сохранить в текстовом файле.

Выбор формата вывода

C помощью опции -o можно преобразовывать данные логов в различные форматы, что облегчает их парсинг и дальнейшую обработку, например:

$ journalctl  -u nginx.service -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

Объект json можно представить в более структурированном и человекочитаемом виде, указав формат json-pretty или json-sse:

$ journalctl -u nginx.service -o json-pretty

{
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

Помимо JSON данные логов могут быть преобразованы в следующие форматы:

  • cat — только сообщения из логов без служебных полей;
  • export — бинарный формат, подходит для экспорта или резервного копирования логов;
  • short — формат вывода syslog;
  • short-iso — формат вывода syslog с метками времени в формате ISO 8601;
  • short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
  • short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
  • verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).

Просмотр информации о недавних событиях

Опция -n используется для просмотра информации о недавних событиях в системе:

$ journalctl -n

По умолчанию на консоль выводится информация о последних 10 событиях. С опцией -n можно указать необходимое число событий:

$ journalctl -n 20

Просмотр логов в режиме реального времени

Сообщения из логов можно просматривать не только в виде сохранённых файлов, но и в режиме реального времени. Для этого используется опция -f:

$ journalctl -f

Управление логгированием

Определение текущего объёма логов

Со временем объём логов растёт, и они занимают всё больше места на жёстком диске. Узнать объём имеющихся на текущий момент логов можно с помощью команды:

$ journalctl --disk-usage
Journals take up 16.0M on disk.

Ротация логов

Настройка ротации логов осуществляется с помощью опций −−vacuum-size и −−vacuum-time.

Первая из них устанавливает предельно допустимый размер для хранимых на диске логов (в нашем примере — 1 ГБ):

$ sudo journalctl --vacuum-size=1G

Как только объём логов превысит указанную цифру, лишние файлы будут автоматические удалены.

Аналогичным образом работает опция −−vacuum-time. Она устанавливает для логов срок хранения, по истечении которого они будут автоматически удалены:

$ sudo journalctl --vacuum-time=1years

Настройка ротации логов в конфигурационном файле

Настройки ротации логов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:

  • SystemMaxUse= максимальный объём, который логи могут занимать на диске;
  • SystemKeepFree= объём свободного места, которое должно оставаться на диске после сохранения логов;
  • SystemMaxFileSize= объём файла лога, по достижении которого он должен быть удален с диска;
  • RuntimeMaxUse= максимальный объём, который логи могут занимать в файловой системе /run;
  • RuntimeKeepFree= объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
  • RuntimeMaxFileSize= объём файла лога, по достижении которого он должен быть удален из файловой системы /run.

Централизованное хранение логов

Одной из самых распространённых задач в работе системного администратора является настройка сбора логов с нескольких машин с последующим помещением в централизованное хранилище.

В systemd предусмотрены специальные компоненты для решения этой задачи: systemd-journal-remote, systemd-journal-upload и systemd-journal-gatewayd.

С помощью команды systemd-journal-remote можно принимать логи с удалённых хостов и сохранять их (на каждом их этих хостов должен быть запущен демон systemd-journal-gatewayd), например:

$ systemd-journal-remote −−url https://some.host:19531/

В результате выполнения приведённой команды логи с хоста some.host будут сохранены в директории var/log/journal/some.host/remote-some~host.journal.

С помощью команды systemd-journal-remote можно также складывать имеющиеся на локальной машине логи в отдельную директорию, например:

$ journalctl -o export | systemd-journal-remote -o /tmp/dir -

Команда systemd-journal-upload используется для загрузки логов с локальной машины в удалённое хранилище:

$ systemd-journal-upload --url https://some.host:19531/

Как видно из приведённых примеров, «родные» утилиты systemd для поддержки централизованного логгирования просты и удобны в работе.

Но они, к сожалению, пока что включены далеко не во все дистрибутивы, а только в Fedora и ArchLinux.

Пользователи других дистрибутивов пока что приходится передавать логи в syslog или rsyslog, которые затем пересылают их по сети. Ещё одно решение проблемы централизованного логгирования было предложено разработчиками утилиты journal2gelf, включённой в официальный репозиторий systemd: вывод journalсtl в формате JSON конвертируется в формат GELF, а затем передаётся приложению для сбора и анализа логов Graylog. Решение не очень удобное, но ничего лучше в текущей ситуации придумать нельзя.

Остаётся только ждать, когда «родные» компоненты будут добавлены во все дистрибутивы.

Заключение

Как видно из проделанного рассмотрения, systemd journal представляет собой гибкий и удобный инструмент для сбора системных данных и данных приложений. Высокого уровня гибкости и удобства удалось добиться, во-первых, благодаря централизованному подходу к логгированию, а во-вторых — благодаря автоматической записи в логи подробных метаданных. С помощью journalctl можно просматривать логи, получая необходимую информацию для анализа работы и отладки различных системных компонентов.

Если у вас есть вопросы и дополнения — добро пожаловать в комментарии. Разговор о systemd и его компонентах будет продолжен в следующих публикациях.

Читателей, которые по тем или иным причином не могут оставлять комментарии здесь, приглашаем в наш блог.

Новости о Docker

Это архивная статья

Наконец-то в Docker внедрили верификацию образов.

Не так много и понадобилось времени, кстати. Ни на что не намекая, предположим, что на подходе зависимости между образами докера, как в RPM.

Помимо этого, в версии 1.8 появилась фича "копировать файл из хоста в контейнер". Не то, чтобы нас, пользователей контейнеров, управляемых systemd, и виртуалок, к которым есть libguestfs, это сильно удивило. Нас больше заинтересовало то, что все эти "новинки" всерьез называются новинками.

Вообще, пользователи Docker зачастую не очень понимают, что такое "контейнеры", что такое "докер" и многие другие вещи. Для них порекомендуем ознакомиться с короткой тематической хаутушкой, которая может помочь расставить все на свои места. Docker, сам по себе, это такой "mc" для контейнеров, и некоторые считают, что как и mc, так и в Docker ничего, кроме лишней сущности, нет. Есть даже шуточная (или не очень?) попытка реализовать Docker в менее 1000 строчек на Bash. Конечно, одним systemd-nspawn вместо Docker обойтись не получится - нужно управление сетью, нужны средства развертывания образов, нужен хотя-бы простейший менеджер задач в кластере, но и для Docker необходимы дополнительные средства.

Например, послушайте любопытное выступление Александра Тарасова, инженера Альфа-банка: Какое у вас сложилось впечатление о развитости и интегрированности компонентов инфраструктуры для Docker? Вообще, про Docker сейчас интереснее читать не статьи, а читательские комментарии к ним, вот тут, например. Похоже, что мы проходим первый пик известной кривой, и пользователи уже сформировали список желаний. При всем уважении к мнению и опыту команды Iron.io с их колоссальными числами реально работающих контейнеров, у Docker есть хорошо видимые проблемы - особенно обратите внимание на файловую систему, журналирование и безопасность. Мы уверены, что эти проблемы преодолимы, и не факт что в каких-то реальных конфигурациях они обязательно вылезут, но в других решениях эти проблемы уже устранены, и это просто надо знать, прежде чем делать выбор.

К счастью, все контейнерные технологии на самом деле базируются на одних и тех же существующих механизмах ядра, и унификация инструментов гораздо выше, чем считают некоторые. Например, развернув контейнер с помощью Docker вы сможете управлять им из systemd, который давно уже умеет напрямую импортировать образы Docker.

Но прогресс прогрессирует прогрессирующе, и Open Container Format, о котором вы уже слышали, скоро сделает ненужным и экспортирование - все контейнеры будут одинаковыми.

Пока утрясаются управленческие моменты, но уже есть инициативы по стандартизации все больших и больших областей, например, сети для контейнеров (но это пока секрет!). Само собой, мы тоже используем Docker сами и помогаем другим.

Пару-тройку недель назад наш коллега, Dan Horák, наконец-то собрал Docker для архитектуры s390x.

Использовался gcc-go, т.к. референсный golang почти никакие нестандартные архитектуры не поддерживает. Напомним, первые эксперименты по сборке чего-то реального с gcc-go начались в апреле 2015го.