В issues проекта Kubernetes обсуждается потенциально опасная уязвимость в парсере YAML-документов kubectl (на стороне клиента) и API Server (на стороне сервера), которая может привести к разновидности DoS-атак под названием billion laughs.



Для уязвимости уже зарезервирован номер: CVE-2019-11253, — однако детали CVE всё ещё не опубликованы. Широкой общественности о проблеме стало известно в результате обсуждения «YAML-бомбы» для Kubernetes API на Stack Overflow.

Всем известно, что Symfony состоит из набора классов, работающих вмесете, но, отделенных друг от друга. Каждый из них может быть использован отдельно. Так, например, в своем проекте, не основанном на Symfony вы можете использовать библиотеки для работы с YAML или роутингом. На самом деле YAML-классы активно используются такими проектами как Doctrene и PHPUnit, а pookey.co.uk опубликовало интересную статью по использования роутинг-классов.

Однако, до этого момента такиму использованию классов не уделялось должного внимания и мало кто это делал. Мы решили, что многие библиотеки заслуживают большего внимания и решили публиковать их отдельно в проекте, называемом Symfony Components.

Введение

Разработчики нередко встречаются с проблемами конфигурации приложений, обычно для этих целей используется XML, в данной статье я хочу обратить внимание на более дружелюбный язык разметки.
YAML (YAML Ain’t Markup Language) – язык (существует с 2001 года) для серилизации данных, ориентированный на чтение и редактирование человеком типичных структур данных. Язык, как нетрудно догадаться, межплатформенный. Известен, в большинстве своём, использованием в Ruby On Rails в качестве средства конфигурирования. Подробнее на русском здесь: http://ru.wikipedia.org/wiki/Yaml

Недавно стал пользоваться программой MySQL Workbench. Приложение меня очень порадовало, в нем очень удобно проектировать структуру базы данных, которую затем можно легко экспортировать на сервер Баз Данных (Forward Engineering). Так же можно использовать обратную разработку (Reverse Engineering): создание ER диаграммы по существующей структуре Базы Данных. Кроме того, в приложении есть синхронизация модели и существующей БД, что тоже очень удобно при разработке.

Но так как мы разрабатываем наши продукты с использованием ORM Doctrine, то кроме структуры БД необходимо было создать модели для доступа к данным. Как оказалось, что для Workbench есть дополнение, которое создает Doctrine YAML сразу из приложения. Немного поискав в инете, плагин был успешно найден. Страница разработчика находится вот здесь.

Используя данный плагин очень удобно и быстро можно создавать схемы для будущих моделей.

Добро пожаловать в GitHub Reflog — еженедельную хронику замечательных репозиториев GitHub и активности сообщества. Предыдущие выпуски доступны в Архиве Reflog.

Сегодня зарелизен свеженький модуль для работы с .yaml конфигурационными файлами. Как обычно, доступен общественности на github Config::YAML::Modern, в CPAN будет добавлен немного позднее Config::YAML::Modern.
Почему этот модуль может быть вам интересен? Он умеет несколько клевых трюков, например:

• корректно смерджить пачку .yaml файлов из директории
• преобразовать file.name.yaml имя файла в { File => { Name => { _content here_ } }
• предоставляет чумовой path-resolution в dive-стиле qw/File Name inner_hash 0 my_key/

Области применения? Навскидку — конфигурация проекта при коллективной работе!
Интересно? Подробности под катом.

Сегодня начал верстать очередной сайт и по привычке пошел на www.yaml.de, чтобы скачать самую свежую версию моего любимого CSS-фремворка и… не узнал внешний вид сайта.

Оказывается вышла новая версия, которая по прежнему осталась очень компактной (ядро 4.6 kB) и обеспечивает хорошую поддержку браузеров

В качестве предисловия скажу что мне всегда нравился yaml. Так сложилось что я по большей части работаю с Zend Framework Но к сожалению ZF долго не поддерживал yaml. Тогда я добавил простой класс который был оберткой для Symfony компонента sfYaml и начал по-тихоньку использовать yaml в своих проектах.

Наконец-то в ZF 1.11.12 добавил Zend_Config_Writer_Yaml и я решил переконвертировать конфиги из ini в yaml

Поработав на некотором количестве веб-проектов в роли frontend/backend-разработчика/верстальщика в разных компаниях, я постоянно сталкивался с неэффективным и некрасивым подходом к задаче подключения необходимых статических ресурсов (будем пока считать это .css и .js файлы) для отображения на странице.

Основная проблема всех повстречавшихся мне подходов — это тесная связь между структурой frontend кода, логикой деплоя и backend кода (в основном шаблонов), а также отсутствие семантики. Далее под термином frontend-код будет подразумеваться вся совокупность .js, .css и каких-либо других файлов или ресурсов, которые отдаются браузеру. Как правило этими файлами занимаются frontend-разработчики (sick!).

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

Продолжая рассказ про наш маленький (но очень отважный) arcanoid, я не могу не упомянуть о таком замечательном языке как YAML. Любая, даже самая простая, игра должна хранить массу данных, таких как: описание уровней, текущее состояние настроек, список достижений и т.п. Желательно, чтобы все это хранилось в понятном человеку и легко редактируемом виде. Традиционно, для этих целей используется XML, но он весьма многословен и его вряд-ли можно считать удобным для ручного редактирования.

YAML существенно лаконичнее, и сегодня, мы научимся им пользоваться.

Не успело Rails сообщество оправиться от последних критических уязвимостей с YAML парсингом, как злоумышленники нанесли удар по святому — RubyGems.org(wiki) подвергся хакерской атаке, через выше описанные уязвимости. Как минимум один зловредный гем был залит на RubyGems, который потенциально имел доступ к чувствительной информации, включая права на манипулирование гемами.

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

Jekyll на Хабрахабре уже светился. Коротко говоря: это система генерации статических сайтов, ориентированная на блоги. Основная особенность: используется на Github Pages, что позволяет держать исходники сайта в репозитории на Github — а несколько кэширующих серверов его в пределах 10 минут после коммитов будут собирать и отображать посетителям. Если интересно больше и коротко: рекомендую к прочтению эту статью, часть материала которой я упомяну и здесь. А я расскажу о Jekyll поподробнее: как им можно пользоваться по назначению, для чего им пользоваться не по назначению, и на что он вообще способен. Статья ориентирована больше на тех, кто ни с чем подобным ранее не работал (как я, работавший ранее с WordPress), и в большей части статьи Jekyll будет рассматриваться именно как средство ведения блога, хотя ближе к концу будет нечто совсем другое.

Из всех существующих платформ для блогов (движков, сервисов, генераторов) Jekyll мне показался странно выделяющимся. Это скорее моя вина, потому что статическими сайтами я увлёкся не так давно и аналогов не знаю. Jekyll ориентирован на технически грамотных людей, которых больше интересует использование блога по его прямому назначению: публиковать посты в обратном хронологическом порядке, а также обеспечивать более-менее удобную навигацию. Если вам нужно больше, придётся либо попотеть, либо отказаться от большего (ну, или от Jekyll). И такой способ «общения» во многом определяет круг пользователей этой платформы: те, кому нужен сайт с предельно понятной им структурой и минимумом проблем в публикации новых постов.

Иногда open source проекты переводятся на множество иностранных языков. С одной стороны это делает их более доступными для широкого круга пользователей, но с другой стороны, все эти переводы нужно поддерживать. Переводы обычно разделены по yaml-файлам и выделены в отдельную директорию, содержимое которой выглядит примерно так: en.yml, ru.yml, de.yml…

Refinements

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

Теперь к методу #using для активации уточнений на уровне файла добавился метод Module#using для активации в пределах модуля. Однако использование уточнений по-прежнему ограничено лексической областью видимости, т.е. они не будут активны при повторном открытии модуля.

Здравствуйте, меня зовут Дмитрий Карловский и я… много думал. Думал я о том, что не так с XML и почему его в последнее время променяли, на бестолковый JSON. Результатом этих измышлений стал новый стандарт формат данных, который вобрал в себя гибкость XML, простоту JSON и наглядность YAML.

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

Больше — лучше	JSON	XML	YAML	INI	Tree
Человекопонятность	3	1	4	5	5
Удобство редактирования	3	1	4	5	5
Произвольная иерархия	3	3	3	1	5
Простота реализации	3	2	1	5	5
Скорость парсинга/сериализации	3	1	1	5	5
Размер в сериализованном виде	3	1	4	5	5
Поддержка поточной обработки	0	0	5	5	5
Бинарная безопасность	3	0	0	0	5
Распространённость	5	5	3	3	0
Поддержка редакторами	5	5	3	5	1
Поддержка языками программирования	5	5	3	5	1

Сейчас очень популярна тема сетевой автоматизации. Одним из инструментов такой автоматизации в мире Juniper является библиотека PyEZ, разрабатываемая командой Джереми Шульмана (Jeremy Schulman). PyEZ — это микро-фреймворк для удаленного управления и автоматизации устройств Juniper, написанный на языке Python. Основным преимуществом PyEZ является его простота и нацеленность на аудиторию сетевых инженеров, а не программистов.

Некоторые возможности PyEZ:

• Сбор «фактов», таких как серийный номер, версия ОС и т.д.
• Извлечение оперативной (аналог команд show) информации
• Извлечение конфигурации
• Изменение конфигурации

В этой статье я бы хотел остановиться на возможности извлечения оперативной информации на примере коммутатора EX4200.

В этом посте я расскажу про не очень известные особенности языка YAML.

Пролог

Системное администрирование за последние несколько лет несколько изменилось. Вместо маленьких скриптиков на bash у нас теперь огромные проекты системы конфигурации. Puppet с миллионом модулей готов «отконфигурять» для нас любую машинку, все поставить и все настроить. И конечно же, венчает это торжество автоматизации Hiera — система управления системой управления.

В начале идея выделения всех конфигурационных данных в иерархическую структуру и редактирования красивых и удобных YAML файлов кажется невероятно соблазнительной, особенно если вспомнить множество форматов конфиг-файлов, создатели которых, кажется, участвовали в соревнованиях по оригинальности мышления. Однако очень уже скоро мы оказываемся с тысячами строк YAML. Давайте посмотрим как можно использовать YAML чтобы наши конфигурации было легче читать и поддерживать.

Сегодня вышел текст о том, как человек перешёл с Sublime на VIM. В комментариях, как обычно это бывает, появились сообщения в духе "Зачем мне тратить время на Vim, если есть IDE, где всё работает?" (люди даже статьи на эти темы пишут). Хотел внести свои пять копеек, но объём написанного плавно перевёл текст из разряда "комментарий" в разряд небольшой статьи.

В целом, всё, что ниже — это вкусовщина, конечно. Нравится вам ваша IDE (или ваш текущий инструмент), да и пожалуйста. Используйте для текущих задач то, чем вы владеете лучше всего, это аксиома эффективной работы. Но если у вас вдруг появилось немного времени на повышение вашей эффективности в целом, то попробую вас заинтересовать именно Vim'ом, сравнивая его с некой обобщенной IDE.

AXON — это нотация для сериализованного представления объектов, документов и данных в текстовой форме. Она объединяет в себе простоту JSON, расширяемость XML и удобочитаемость YAML.

Есть проект pyaxon на python, с которым можно "поиграться". Впрочем, он создавался таким образом, чтобы не сильно уступать по скорости с модулем json. Поэтому он может сгодиться и для реальных дел.

Зачем AXON?

AXON появился как попытка справиться с недостатками или неудобствами JSON и XML, но сохранить при этом их достоинства и возможности, дополнительно добавив удобочитаемость, присущую YAML.